Earlier quoted context omitted.
Well, did we? You can still do that! Those environments were extremely primitive and it doesn't take much work to match or vastly exceed their capabilities. This is so much the case we often don't even recognize such environments staring us in the face. Consider another story on the HN front page right now: IntelliJ 2021 is out. Load IntelliJ and you have something that which can be arbitrarily scripted, altered and…
IntelliJ idea is, in many ways, more advanced than Genera, yes. I use it every day. But I stand behind my assertion that we've lost something there: Genera had most of the features you listed (even though I didn't have time to show them), and in the case of debugging the debugger, AFAIK, you can't get IntelliJ into a state where the debugger is debugging itself, because in order to attach a debugger to an instance of…
I think as part of that you'd need to teach the debugger how to attach to itself without risk, probably by defining some notion of a protected system thread and then preventing breakpoints from affecting them. The JVM is certainly capable of doing this, although the debugger UI would have to be extended. I guess Genera either didn't have breakpoints or had some equivalent notion of un-breakable operations.
It's true that there's no way to just edit a single function and replace it, at least not out of the box. This is partly conceptual - Symbolics Lisp was pretty much a dynamically typed language if I remember correctly, as are most Lisps, and didn't have any real notion of version control or a compiler checking things for you ahead of time. You wouldn't want to edit only a single function in isolation if editing the internals of IntelliJ because a lot of the value of the tooling is putting the code in context via type checking, static analysis, folding and so on, which requires the rest of the code to be available and ideally visible.
Still, there's nothing missing from the core technology. To make things editable like that you could have a plugin that grabs the matching source zip for a selected symbol or bit of UI and opens it in a new project window, configured in such a way that compiling it causes it to be reloaded into the IDE. Either via the plugin reload mechanism or the bigger hammer of something like DCEVM, which lets you arbitrarily redefine classes at runtime even if their field layout changes. It's more of a workflow issue than anything else. The additional overhead is mostly buying you things you'd want anyway, like a notion of sharing and version control for your changes.