Hi Ben,
IMO this is something that one does only on a major release such as the Squeak 4.x to 5.0 and Pharo 5 to Pharo 6 V3 to Spur transition. The VM should strive to be backward compatible, whereas images are forwards compatible. This allows the VM to be upgraded to fix bugs & add new functionality. And this policy is achievable in practice. IME, both VisualWorks' HPS and Cog and the Squeak interpreter VM (& I'm sure other Smalltalk VMs) have always provided this approach.
I don't see the providing of a setting to enable high dpi as a good reason for changing the VM version mid-stream, with all the inconvenience for users that this implies:
For users, they have to maintain two VMs and the ability to launch them plus being able to tell which is which; easier for users of Pharo launcher, but not something to be complicated unnecessarily.
For VM maintainers dropping backwards compatibility implies adding another VM to maintain and back port fixes to. It's already costly to maintain the V3/Spur VMs (e.g. adding the allocated bytes accounting for Spur requires a guard clause to avoid impacting the V3 vm). So we have to keep the matrix to a minimum.
I'm happy to expand the matrix for experiments that look like offering my a large future payoff such as Sista and Lowcode (& indeed Spur) and to continue to support older versions for as long as we as a community think make sense. But we should avoid doing this wherever possible. Resources dictate.