But that's not a relevant concern.  A new image can always be run on an updated VM.  The issue is to *not break older images*.  A VM on its own is not an application; it is analogous to a real piece of hardware.  An image, on the other hand, *is* an application.  New VMs should *never* change the semantics of older images with which they're compatible.  That's akin to a newer processor running older binaries incorrectly; entirely unacceptable.

Here's what the Go designers have to say about the issue in the latest CACM:

"A final kind of consistency is that of the language and libraries over time. For the first few years of Go's existence, we tinkered with and adjusted it in each weekly release. Users often had to change their programs when updating to a new Go version. Automated tools reduced the burden, but manual adjustments were also necessary. Starting with Go version 1, released in 2012, we publicly committed to making only backwards-compatible changes to the language and standard library, so that programs would continue running unchanged when compiled with newer Go versions. That commitment attracted industry and has encouraged not just long-lived engineering projects but also other efforts, such as books, training courses, and a thriving ecosystem of third-party packages." (my emphasis added)

This is a rational approach to backwards compatibility, and is one most Smalltalk VMs, and certainly all the ones I've been associated with, have maintained.  It is OK to change the VM to no longer support older images; it is *not* ok to break older images in a VM upon which those images still run.