The fact that ia32 (and it's sub-classifiers: i386, i486, etc) is still somewhat used, while amd64 has almost completely disappeared is 100% due to Intel's marketing shenanigans in the 00s.

Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes.

The primary ("first byte") opcode space is quite busy in 32-bit mode. Intel and AMD figured out a way to "hide" extra instruction prefixes in illegal modes of certain 16/32-bit instructions. Intel did this with the VEX prefix and AMD did it with the XOP prefix. The instructions they chose were LES/LDS and POP. This is the reason why some of the bits in those multi-byte prefixes have to be inverted, btw.

Having 4 clean bytes available with no need for such silly games should prove useful in the future.

The 4 string I/O instructions they suggest removing will be useful immediately.

Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code. This could perhaps be used to provide shorter aliases of certain existing encodings -- so the instructions in question would still be available for kernels but applications would see better encoding density.

And then there is the 67h byte being freed as well due to removing address size overrides.

If they are sensible, they will also remove the BOUND instruction from 32-bit mode, but that is not in the current version of the plan.

So what are the benefits?

Free space in the primary opcode map => better encoding density... and they might not be doing this to give us shorter programs. They might be doing this so the parallel instruction decoders can handle more instructions per cycle.

Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls).

They also get to remove lots and lots of special cases that undoubtedly cost engineering time and validation time.

This is somewhat beyond my knowledge of system programming, but my read is that it's just possible to support 32-bit guest kernels in the VM with some more emulation of the de-supported instructions. I don't know how many of those instructions already cause VM exits.

  If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example. 

So please explain.

If it's 2% of instruction cost, then kill it with fire. If it's raising the development cost by 1%, kill it with fire. If it's a fixed cost and isn't hurting anything, then meh.

I don't believe it's that simple (or obvious, since you seem to be mistaken).

   why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic?

So, you could build a PC based LPAR hypervisor. It would just be limited to the SRIOV capable devices, or plugging in piles of adapters, each one uniquely bound to a single partition. Ex: https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf

Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver

Namely, planned obsolescence. They realised that forcing people to consume could squeeze a little more $$$ from them.

Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.

https://airborn.com.au/layout/vddtest.html

A 16-bit DOS application using DirectX..

In the case of OrCAD this was very easy because it already had plug-in architecture for graphics. It had this because even the mouse was not standardized in the early days.

but also it's a stretch in general as for personal computers arm is the dominant platform since years (there are way more phones, tablets, etc. then x86 laptops/desktops by now, all of which fit the original definition of personal computer)

  Easing the transition until x86 can be relegated to emulation. 

Or I guess you could look at it another way, CISC won because it turns out that implementing specific high level functions like say AES, memcpy or vector ops are better implemented with explicit hardware blocks, or provide additional hinting that gives the micro architecture an advantage, while the costs of cracking inconvenient sequences into simpler ones means that effectively the processor designer has the choice between attempting to build hardware for something like Arm's Load/store Multiple or simply breaking it into a sequence of uOps (which one might suggest is basically the modern equivilant of micro code).

And this is why I'm a bit skeptical of RISC-V at the moment. No serious architect of high performance microprocessors can think that designing an architecture to match a modern low transistor budget microcontroller is a good design choice. Because like every other single RISC processor, what happens over time is that they are forced to add higher level instructions for the additional hinting they can provide. If you look at the past 10 years of arm architecture updates you can read between the lines of "the RISC solution for X we were using couldn't compete with vendor Y's product so we added this instruction/etc to solve the problem". Same with POWER, they even gave up on their famous inverted page tables because it was basically a software managed TLB and it turns out building page walking hardware is a better solution than writing software to do it. Its also how no one takes a processor without some kind of SIMD seriously anymore.

That said, its not like RISC-V can't evolve into something "good enough" its just going to be stuck with a bunch of ugly baggage by the time it gets there because its starting with a false set of premises.

The devil reveals itself. Competitors have infected Intel and are trying to destroy it from within.

x86 without the legacy is just another ISA, and Intel is going to lose if it tries to go down that path.