I don’t mean to suggest that the involved parties don’t know about microarchitectural implementations. Names aside, it’s clear from reading the RISC-V documents

I don’t mean to suggest that the involved parties don’t know about microarchitectural implementations. Names aside, it’s clear from reading the RISC-V documents that they do. And I don’t mean to imply that they’re wrong about the various “unclean” elements of other RISC ISAs being bottlenecks, either. All I mean to say is: as academic designers of a license-free ISA in the 2010s, to whatever extent they’re incentivized at all, they’re incentivized towards designing a “simple” and “elegant” ISA regardless of the concrete impact on performance or die space in a way that the MIPS, SPARC, and ARM teams in the early 80s - designing for commercial production and profitability using the processes of the time and their limited resources - weren’t. That’s not necessarily a criticism - but the consequences of their decisions on performance and adoption are harder to say. You’re claiming otherwise, but without further evidence and based on my personal understanding of architecture and microarchitecture design I believe that ceteris paribus a low-end RISC-V implementation is likely to perform worse and use more silicon than the corresponding MIPS, ARM, or SPARC implementations. A high-end speculative, out-of-order, modern process, etc RISC-V implementation would likely be able to outperform a similar one for those architectures with less silicon. The question for me is whether we get to the point where the market builds one, and whether those potential performance improvements would (alone or in tandem with RISC-V’s other benefits) justify adoption.