> RISC ISAs were intended to be programmed exclusively in high-level languages and never in assembly language.
> That's a misunderstanding. RISC was designed to include only the instructions that high level language compilers found useful. There was never any intention to make assembly language programming difficult.
That is no misunderstanding, but almost a quotation of the 4th point in the definition of the term "RISC", in “RISC I: A Reduced Instruction Set VLSI Computer”, David A. Patterson & Carlo H. Sequin (University of California, Berkeley), presented at ISCA '81.
Of course they did not try to make assembly language programming difficult as a goal, but the theory was that no ISA feature should be provided with the purpose of making the assembly programming easy, because it was expected that any inconvenience shall be handled by a compiler for a high-level language.
In practice, only the academic RISC ISAs from Berkeley and Stanford were less convenient to program in assembly language, while those from the industry, like IBM 801 and ARM and their successors did not have any disadvantage for programming in assembly language, on the contrary they were simpler to program than many less orthogonal older processors.
RISC-V has everything needed only in the same way as an UNIVAC from 1950 has everything needed.
As an ISA for didactic hardware implementation, RISC-V is very good. As a target for writing programs it is annoying whenever you are writing non-toy programs.
RISC-V has only one good feature in comparison with x86 or ARM, the combined compare-and-branch instructions, which saves a lot of instruction words in comparison with separate instructions, because branches are very frequent, e.g. one branch to every 6 to 8 instructions.
Except for that, there are too many important features that are missing without absolutely any justification and without any benefit.
Detecting integer overflow in hardware, like in almost all CPUs ever made, with the notable exceptions of Intel 8080, RISC-V and a few other that have never pretended to be suitable for general-purpose computing, is exceedingly simple and cheap. Detecting integer overflow in software is complicate and very expensive.
Implementing indexed addressing in hardware is extremely simple in comparison with implementing instruction fusion or with increasing the number of functional units and increasing the width of all structures to be able to execute more instructions concurrently, in order to reach the same performance for an ISA without indexed addressing.
While the loops of RISC-V usually save an instruction at the loop test, they waste at least one instruction at each memory access, so except for very simple loops RISC-V needs much more instructions for executing an interation than most other ISAs.
The RISC-V proponents have bogus excuses, i.e. the availability of the compressed mode and the possibility of using instruction fusion. These 2 are just workarounds for a bad instruction encoding that requires an excessive number of instructions for encoding any program. They can never be as good as a well designed instruction encoding.
All competing ISAs that are better encoded can also implement a compressed encoding (like ARM, MIPS and POWER also have) and they can implement instruction fusion. They seldom do this only because they seldom need this, unlike RISC-V.
I have programmed in about the same list as ISAs as enumerated by you, over about the same time interval. I agree that for most controller tasks RISC-V is acceptable, even if sub-optimal. When it is cheap enough (due to no royalties) that can overcome any other defects. On the other hand I have also written various programs dominated by complex computations, where the deficiencies in arithmetic and array addressing of RISC-V would have made it clearly unacceptable.