As far as I can tell, I think the cycle count is intended to model the cost of cycles against your 100KHz budget. I'm not sure I think it's worth the complexity.

Given that Notch seems to want to continuously operate one or more virtual CPUs for every user, if it were me, I'd favor making the execution model as simple and cheap as possible.

Why do you care when the result is available if the next instruction will run after the wait is complete?

I guess it matters if another CPU can read your memory and depends on the cycle count to synchronize...

It also matters if writing to the memory causes an actuator to... act.

Picture if memory location 7 is mapped to how much energy to pump into the laser cannon.

In which case interaction happening when you send the command and not at a command-specific during the execution should simplify things?

If it's supposed to take 3 clock cycles to execute an instruction, then it's "unfair/unrealistic" to really activate the laser cannon instantly, and then make the processor wait 3 clock cycles before it begins to execute the next instruction.

It'd be "more fair/realistic" if it took 3 clock cycles, and THEN the memory was overwritten.

Note: this is debating the timing of a 100 kHz simulated processor, within a game... so, the discussion is kind of inherently pedantic. =)