Reply to post:

"The core processing on x86 is still 32-bit which is why everyone in the world didn't have to recode their app in order to work at all on x86-64."

That's not really how I'd phrase it. AMD64 can run 32-bit X86 code natively, but that doesn't make it 32-bit. If you compile for AMD64, you use 64-bit capable instructions, which this has. It's not just a 32-bit processor with larger addressing. So I'm not sure what you're trying to say with the part I quoted. I have two ideas:

1. "AMD64 is 32-bit even when you compile to its ISA natively": That's incorrect, but I don't think that's what you're saying.

2. "It would be better if the transition to 64-bit required everyone to recompile for it so we got the benefits faster": I get the idea, but I don't know that it's been a major problem. We've had 64-bit desktops and laptops for over a decade now, and you can pretty much guarantee that most users today have a 64-bit OS and most of the performance-sensitive programs they run on it are also 64-bit. The occasional old or small program still runs under X86, but that's only a problem if it will actually benefit the user by using the faster instructions or more memory. Quite frequently, such programs don't need to be that fast.

For that matter, we also have ARM64, which is like AMD64 in that it can coexist with previous versions of the ISA. Still, most mobile devices that are powerful enough (phones, tablets, not the SOC running the embedded devices), are using a 64-bit OS and apps compiled natively to it. ARM is even planning to drop 32-bit support in their next range of high-end cores because so many people never use the 32-bit capabilities.

Meanwhile, the ability to run stuff without having to recompile it means people will adopt 64-bit hardware faster. When the software supporting it comes out later, they already have the ability to run it, and having the hardware themselves, they can also compile and test their stuff to run under it as well. The overlay method makes some sense given those benefits.