Jonathan Edwards 🤗 sorry mate, I've had a glass of wine and became un-inhibited in my public communications style Lu Wilson

No worries mate. I linked to the 2020 program instead, which was better. You should write a paper.

Thank you for all 3 of those statements. 🙏 🤗

I would enjoy learning more details about why and how this works under the hood. Details / links / discussion.

I would also enjoy this. I haven't seen any other related publications about this project.

I suggest that we discuss and try to reverse-engineer.

Allow me to begin with an opening salvo. Comments & push-back expected.

If I think only of an MVI (Minimum Viable Implementation - ignore all concerns for "efficiency"), I see something fairly simple:

Basically, the REPL (the slider) clears the IDE state, peels one frame-state out of the frame-state array (database, whatever) and loads that state into the IDE, re-rendering the game window and the editor window. Re-loading the source code can use git-like technology. Re-loading the display list and the debugger state means pasting binary data. If you convert the binary data to text, you can use git here, too.

If you own the code for the debugger, the game display engine and the editor engine, then it shouldn't be a problem to ensure that they all use data that is wholly contained in some convenient state location(s) that can be serialized and deserialized to a database. Modern dev machines are fast and memory-endowed, so there is no reason to optimize this stuff until proven guilty.