Thanks for raising all of these points. I think issues around zk friendliness have a higher profile, so I want to echo especially the first two points and add a particular piece of data. In recent work relating to RISC-V compliance testing and fuzzing, I ran into ttps://github.com/riscv-software-src/riscv-tests/issues/368 (sorry, I can’t post links yet). In brief, since at least January 2022, if you have implemented the current version of the base instruction set (or, say, RV32IM, which some of the zkVMs use), then these canonical RISC-V tests crash your implementation. This is because some macros used to set up the tests make use of instructions that have been removed from the base instruction set.
Like @gballet, I feel that RISC-V is an awesome project worth supporting. I’m just raising the point that a flexible standard and lots of existing tools does not necessarily mean easy bootstrapping to meet our needs.
Let me also explicitly say that I this issue is, to me, separate from whether we can deploy L2 scaling in the short and medium term via RISC-V based VMs. Of course there could be some synergy there, but IMO that synergy would come too far down the road to consider now, given the pace of development of zk and the more immediate need to scale.