I've been doing repl-driven development with Common Lisp compilers for about 33 years now. I have never ever worked in the way that you describe, and have never witnessed anyone else working that way, either.
It would be a nightmare for maintainability if anyone worked that way, but if they do, I haven't ever seen it.
I do write the state of the runtime to image files from time to time for various purposes. I assure you, though, that all the code I write lives in files that are maintained under revision control, and it's been that way for many years, and in all that time I've never been in danger of losing any work because of forgetting to write an image file.
Nevertheless, this still does not add up to precisely what the GP described.
Smalltalk in contrast has GP's model of saving and reloading the VM state.
Interlisp and most Smalltalk systems also offer the convenience of automatic change tracking, writing your changes to the sources file and the changes file, and providing in-image tools for browsing and managing changes, including things like Interlisp’s Masterscope and Pharo and Squeak’s Monticello. These tools make life more convenient for people who prefer to work mainly with the in-image tools and not to mess with text files that much.
But if there’s a Smalltalk system that relies solely on the image file to preserve changes, with no support for other means of change tracking, I’m not aware of it.
Part of the confusion on this point is thinking that the prompt is the repl. It isn't. It's a UI for the repl. The repl is the process that reads, evaluates, and prints, then loops back to do it again.
Nothing about a repl requires there to be a prompt, and not all UIs for repls have them. Interlisp and Smalltalk have relied mainly on promptless UIs for their repls since the 1970s.
When working with Common Lisp, the main UI I use is an Emacs editor buffer and the key bindings that send input directly to the repl (bypassing the prompt). Typing at the prompt is the exception rather than the rule, and I could get along fine if I didn't bother to load the slime-repl contrib that provides it.
It is more than four decades old obvious basic idea, and I do not understand why almost everybody ignores it.
Not an expert, but your changes never 'leave' your source files. You iterate by changing the code in the file, sending it to the image/compiler, and repeat. There's no need for "getting code back into the files".
I send my changes to the repl with the stroke of a key.
Working with a repl doesn't necessarily mean typing text at a prompt. The prompt isn't the repl; it's just a particular UI for the repl.
Smalltalk systems do tend to store edits in the memory image (though they also write them automatically to a changes file and a sources file, so they aren't lost if you blow away your working image). Smalltalkers generally prefer to work in the image and treat text files as a serialization format for exchanging code and data.
But normally there's no question of getting "changes back in your source file" because they were always in your source file, or its equivalent, from the start.
The old ways —
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.
…
The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."
1984 Smalltalk-80 The Interactive Programming Environment page 461
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
The somewhat less old way —
https://www.google.com/books/edition/Mastering_ENVY_Develope...
In other words it was a cultural thing, not a property of the languages. And even with the systems for which that was possible it was also possible to start with a fresh band and load code into it.
The notion that you'll lose your work if you use the normal means of interacting with the repl is a misunderstanding of how such systems work.
If someone did that, they'd be a fool. Common Lisp and Smalltalk, the quintessential REPL-driven languages, have supported storing and loading source from files since their standards were published, and before then since the standards weren't created out of thin air.
Even under Smalltalk, which works more like you say, the system tracks and saves source changes. At least that's how it works under Squeak and Pharo.
Very few developers would be foolish enough to use a heap image as the source of all truth. I'm sure it happens, just like the place I worked at whose entire web stack was based on a magic DLL no one knew how to compile, happened. Like the magic DLL, it's widely considered a terrible, terrible idea.
The workflow is amazing because you write the software in the editor you're used to and have keybindings for interacting with the REPL inside your editor.