Ah, this is
virtualization, though: the OS was trying to
integrate the software from the old OS, letting it interact with all the older APIs of the modern OS as if it was running directly on it. Less like a VM, more like Wine.
My point was less about compatibility, and more about security. If you took this approach, old software would still expose the new OS it was virtualized atop of, to its old security flaws. So you'd still have to move away from old software, eventually, for security reasons.
But with proper VM isolation (and checkpointing, and a few other things), you could still have programs like IE6 around today, serving in its last purpose as the '90s-era Intranet web-services equivalent to the '80s 3270 mainframe terminal clients.
Most any modern VM software can offer this level of isolation, but most have "host integrations" that turn them back into security holes. To be able to ship a static, EOLed copy of XP that could run IE6 indefinitely, without that causing problems, your compatibility layer would need to be a lot less like "Windows XP Mode" or Rosetta, and a lot more like DOSBox or qemu.
There is one case where this already happens: many pieces of IBM z/OS software have been wrapped in layers of hard-isolated emulators for decades now, such that programs from the 70s are able to continue running without recompilation, atop a stack of VMs, where many of the intermediary pieces of VM software have themselves long been EOLed.
