That doesn't seem likely, that wasn't the recommended approach to managing source code in Smalltalk — but I have no personal experience with Self.
Seems like it might depend on which version of Self is being discussed.
"To briefly recap, the Self transporter allows the programmer to take a program that adds some functionality to a snapshot and move that program to another snapshot. It accomplishes this task by writing the slots that comprise the program to a source file that can be read in and evaluated in the new snapshot to recreate the program."
We used to think Ruby would turn out to be important. Then it didn't, and Python reclaimed its niche. I have probably heard of Toit before, but am unsure.
Snapshotting your VM state as the way to deliver programs was probably Smalltalk's chief failing.
> the way to deliver programs
To judge whether that could be successful, we need to be more specific — deliver what kinds-of programs to what kinds-of end-users?
Toit has blocks (lightweight closures), single inheritance, everything-is-an-object (no primitive types).
Like Smalltalk the Toit VM is dynamically typed, but unlike classic Smalltalk there are optional types and they are checked at compile time and run time if you choose to use them.
The syntax is not much like Smalltalk though, and development is with conventional source files and compilation, not image based like Smalltalk and Self.
(In Self the editor was inside the VM and you saved your work by snapshotting the entire VM state which is superficially attractive but makes it really hard to collaborate and use version control.)