I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel e

I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :) The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization." Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box. What specifically would be the comparable trigger for ARM or RISC-V? You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs. I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.