> Since ARM moved to ARMv8, I groaningly refer to v8 as "x86 v2"
I'll have to disagree, I think ARM mostly did the right thing with the A64 instruction set. The AArch32 instruction sets were just getting ridiculous (just having multiple instruction sets for one architecture is pretty messed up), with A32, T32 and a bunch of other extensions (ThumbEE, Jazelle) which pretty much no one used. In addition, the A32 and T32 instruction sets have grown organically over time, with new instructions being crammed in any unused / invalid space, which is how we ended up with one encoding doing this one thing, except if one register is the SP or PC, then that is a whole other instruction or with immediate values being split up over 2, 3, 4 fields. Also, a few features had turned out to be pretty bad ideas: for example access to the PC as a general purpose register is overly complicated to implement in OOO cores (verification cost) and comes with performance penalties, but it still had to be supported; the IT instruction is another fun one, especially in the context of dealing with exceptions.
A64 pretty much takes the set of instructions which has emerged over time, removes the bits which are not suitable any more or were bad ideas in retrospect, fits them cleanly in a new encoding space and removes some of the flexibility which was getting in the way (e.g. VFP having either 16 or 32 double precision registers). I expect AArch32 to be gone from most high performance implementations in a few years, with a software DBT option remaining available for legacy software which still hasn't been ported, which is when the implementers will be able to fully benefit from having a simplified AArch64 compared to AArch32.