In which case, one does not save that image ;-)
Or if one chose to save a broken image, one goes back to a previous image and reloads all the recent changes up-to and excluding the change that broke things.
https://cuis-smalltalk.github.io/TheCuisBook/The-Change-Log....
But it should be very rare, and besides the change log and similar facilities it's also easy to just make timestamped copies of the image and pushing packages to git.
So how would we explore fundamental changes that break the debugger? Would the dumbest workable thing be create subclasses without changing the originals?
I have come across someone who genuinely seemed to think that making copies of just the image was a viable approach to version control. Their project failed badly; and they were absolutely convinced the problem had been Smalltalk, when the problem was not understanding how they could use Smalltalk.
Epitome of fragility.
A different story if you'd gone-on to explain recovery.
The Pharo folks insist on trying to adapt to industry, and that's also the focus of a lot of their published material, though there's still an academic legacy in there.
For me the tricky thing is to find enough time to study the API:s, the programming language is easy to learn the basics of and then one has to figure out the flow in creating a package and adding code to it, but then it's a slog searching and reading the code for hundreds of classes to figure out where the thing one wants resides. On the other hand, when things break it's usually a breeze, the inspection and debugging is great, unless one does the mistake of redefining some core class and corrupts the entire image.