And the better solution is to finally ditch backwards compatibility with the 8086 and implement a sane instruction set that isn't just a virtualized layer à la x86
Additionally, the instruction set is not virtualized because of compatibility. Compatibility is a nice side effect though, so software from even five years ago works just as expected (not all software can be recompiled, and could you imagine commercially supporting that many variants--this way Intel shoulders that burden). And, backward compatibility is a tiny fraction of the control unit silicon area. It has zero performance cost. Zero. Intel is scraping for more (not less) things to add to silicon to improve performance (video encode/decode, GPU, memory controller, PCI).
The virtualized instruction set enables the performance gains by executing portions of instructions in parallel, re-ordering to avoid pipeline stalls, better branch prediction, execution shortcuts depending on operanda, etc. without compiler support. RISC architectures like ARM do this as well. On a modern Cortex part with multiple execution units, the processor is not a textbook pipelined RISC processor like this community seems to yearn for. So if you look at machine code for some reason, yes the instruction set is simple, but it's still a facade over complexity.
I don't understand the constant cry that processors are complex. To gain performance against the frequency limit, complexity increased. This happens with software all the time.
Also, for those that want direct control over all the elements of the processor, go buy an Itanium... oh wait... no one did.
Intel tried that, the Itanium didn't really work out so well. Anyway, a sane instruction set doesn't mean you'll include the proper division tabels in silicon, so you probably still need to have updatable microcode to fix that.
And the better solution is to finally ditch backwards compatibility with the 8086 and implement a sane instruction set that isn't just a virtualized layer à la x86