I think the OP is looking for an explanation that would allow him to know the behavior of the program if he edited the code.
1. The option menu on the outer emulator window (File, Edit, Snapshot, Settings) is some kind of retro operation system (not the inner x64, and not ubuntu). What is it? Is the code I'm writing being executed in this operating system?
2. What VNC program is running a retro operating system in a docker container and why is it so slow?
3. What is the VNC client (security!) and what can I, as a developer, do when things like the VNC client dimensions go wrong, as they do in this example?
The problem with developing on a closed-source code-running platform is that in the end, there will be an error at a layer of abstraction you don't have access to. You've done an excellent job of piecing it together from the blog posts and "?debug=1" hack, but they need to make your job easier.
1. It is an emulator program that has nothing to do with Replit, it is just being run on Replit.
2. To repeat, the VNC program is not running the retro OS, that is the emulator. The emulator is a program which runs on Linux and opens a window to show you the emulated computer's screen. That program is being run on Replit, and you can see the screen because it is being connected to you via VNC. I can't answer for why it's slow; that could be the repl, the VNC connection or the emulator itself.
3. The VNC client is no-vnc (I think) and is encrypted. If there's a bug with it, report it to Replit.
The whole point of Replit is to abstract all of this; at the end of the day it just gives you a browser interface to a VM in the cloud, with a filesystem you can save to between sessions. You just interact with it as you would any other Linux system, as all of these layers of abstraction you don't have access to are just providing this simple interface. You don't even interact with anything outside, so there is absolutely no point in using it when developing anything other than for the Replit system itself.
The problem is that there will always be bugs, and you can't abstract away details unless you provide a clear and consistent interface. Replit neither provides an exact spec for how their system works, nor open-sources their codebase to let developers read how it works. There will be cases when it's impossible to know, "is this is a bug?" That's the definition of undefined behavior.
1. The option menu on the outer emulator window (File, Edit, Snapshot, Settings) is some kind of retro operation system (not the inner x64, and not ubuntu). What is it? Is the code I'm writing being executed in this operating system?
2. What VNC program is running a retro operating system in a docker container and why is it so slow?
3. What is the VNC client (security!) and what can I, as a developer, do when things like the VNC client dimensions go wrong, as they do in this example?
The problem with developing on a closed-source code-running platform is that in the end, there will be an error at a layer of abstraction you don't have access to. You've done an excellent job of piecing it together from the blog posts and "?debug=1" hack, but they need to make your job easier.