I mean, Tcl/Tk has had this since the 90s. Rewrite your procs (functions) on the fly, delete GUI items on the fly, generate new events, create listeners on the fly, etc, etc.
Quite easy to create a GUI that's interactive AND a console you can script on at the same time to inspect / edit / change code.
For example, don't like your window attributes? Write code to destroy it, and re-create it and keep your "live" data unchanged, and it will redisplay in the new style / layout.
And sure, you could code up atomic transactions quite easily.
Itcl even lets you create / add /remove classes or specific class instances on the fly, or redefine class methods.
I concur that TclTk is enormously versatile and productive. I've always regarded Tcl as a Lisp-like language. Tcl and Lisp share characteristics like homoiconicity that enable benefits you describe.
Tcl isn't as widely known and used as it deserves to be. I think that's in part due to its syntax being sufficiently different from "mainstream" languages. The learning curve isn't particularly steep, but enough so that developers question whether it's worth the effort to go there.
FWIW Tcl 9.0 has recently been released. The language has been enriched with sophisticated object-oriented capabilities, coroutines, full math tower, etc. It's also rather easy to write extensions in C.
Anyway, the GUI toolkit (Tk) has been "borrowed" by many other languages (e.g., Python's tkinter), so quite a few programmers use TclTk, know it not.
Never claimed to be innovative, but sadly all these cool features are nowhere to be found in modern languages. And for some reason, they never appeared in a fast(ish) language, even though I'm sure the JVM is very well equipped to handle this kind of dynamism.
Recompiling a method[1], popping the stack frame, and re-entering the new method is a very, very common debugging pattern on the JVM. I miss it every day that I'm on vastly dumber platforms
https://www.jetbrains.com/help/idea/altering-the-program-s-e... -> https://www.jetbrains.com/help/idea/pro-tips.html#drop-frame
1: pedantically, you're recompiling the whole class, but usually it's only one method changing at a time unless things are really going bananas
DCEVM (RIP) allowed swapping the method signature, too, but that is a lot more tricky to use effectively during debugging (e.g. popping the stack frame doesn't magically change the callsite so if you added extra params it's not going to end well) e.g. https://github.com/TravaOpenJDK/trava-jdk-11-dcevm#trava-jdk...