And x86 isn't that nice to begin with, if you do something incompatible, you might as well start from scratch and create a new, homogenous, well-designed and modern ISA.
This isn't an issue in any way. Vendors have been routinely taking out rarely used instructions from the hardware and simulating them in the software for decades as part of the ongoing ISA revision.
Unimplemented instruction opcodes cause a CPU trap to occur where the missing instruction (s) is then emulated in the kernel's emulation layer.
In fact, this is what was frequently done for «budget» 80[34]86 systems that lacked the FPU – it was emulated. It was slow as a dog but worked.
i.e Software compiled for 86 should work on x86. The value for backward compatibility is kept with both Intel and AMD. If the market wants something in between they now have an option.
I know this isn't a sexy idea because HN or most tech people like something shiny and new. But I have always like the idea of extracting value from the "old and tried" solutions.
But thankfully I could install an old bin and lock it out from updating.
Intel’s software development emulator might run the newest bin but variable how slow it might be.
In other circumstances, the AVX extensions aren’t required but the app is compiled to fail if they’re not required: https://www.reddit.com/r/pcgaming/comments/pix02j/hotfix_for...
So it would be faster and more efficient when sticking to the new subset and Nx slower then using the emulation path.
Most architectures other than x86 have fixed sized machine instructions now, making decoding fast and predictable.