> You just simulate the system or just let it execute normally (but under the control of some kind of "harness") "Simulate the system" means "execute normally"

> You just simulate the system or just let it execute normally (but under the control of some kind of "harness") "Simulate the system" means "execute normally" for all practical purposes. That's what TC + Halting Problem[1] essentially boils down to, absent other knowledge about the program. Hence my suggestion to let the program itself do "projection" because it could potentially be hugely more efficient, and possible (but perhaps with bad "fidelity" in the case of side-effecting computation). Anyway... to the larger point and to expound a little: If everything is pure, then there's basically no problem (except computational cost), but imagine our Mario is taking part in a multiplayer game. What do you think should happen? (Obviously, this is not realistic for the reason that you usally don't run "debuggers" or "IDEs" in a 'multiplayer' scenario, but I think the analogy holds in general. Imagine that the other players' actions are I/O operations like "what's the current time?" or "talk to a REST service", etc.) Most interesting programs do this kind of thing all the time. Of course, there are interesting programs/functions which are purely algorithmic and rewind/fast-forward should work for them, but they are mostly pretty niche compared to most of the programming that currently happening. A very interesting example that's somewhere "in between" is Haskell's STM monad which does have very controlled side effects and where you can just "retry" and particular computation in case synchronization fails, but it still doesn't allow you to "project". [1] Alright, I suppose it's just undeciability for non-trivial properties of TCs languages, but Halting Problem is a convenient shorthand.