I think that's actually a bit of a contentious question; I think there's a lot of people that'd argue that it's definitely part of the future of open computing, and I think it's extremely likely that it stays a part of computing for low-cost embedded devices.
On the other hand, there's a strong argument to be made that it's more difficult to make a RISC-V processor with comparable performance to a desktop-grade amd64 processor than to make an ARMv8 processor that with the same. (Personally, I'm a big fan of AArch64 being a fixed-width encoding, and both programming by hand in it and find writing assemblers and disassemblers is super-easy as a result.)
My understanding was that the RISC-V encoding used lengths as decoded in e.g. [0], whereas AArch64 is uniformly 32 bits per instruction; is this incorrect?
That's correct, the compressed extension (part of the desktop spec over my loud and persistent protest) is part of the desktop platform. This adds 16-bit instructions to the 32-bit instruction set.
There are many reasons why this was a huge and very shortsighted mistake, but the most painful part of this is that you can now have an instruction spanning two cache lines. This has many awful implication and precludes many tricks that would make implementations faster. But it was important for Andrew Waterman to get his thesis work be mandatory part of the Unix platform, so here we are.
ADDENDUM: It's near trivial for a linker to pad such that instructions don't span cache lines and that would have made this a lot less painful, but RISC-V refuses to specify the line size (it's implementation dependent), so now we suffer this nightmare.
I'm on the other side. I think ARM ignoring their ultra-successful Thumb2 -- which basically made the company --when designing Aarch64 was a huge mistake.
Pretty much every embedded RISC-V user values the C extension highly, and many even think it doesn't go far enough because it leaves out things such as push/pop multiple resulting in the code being 3% or 5% bigger than Thumb2 code (but much smaller than anything else in current use). Hence there is a working group creating an optional extension including things like that, based on a customer extension Huawei have already deployed in the field.
Having both 2 and 4 byte instruction lengths is a little harder to deal with than having only 4 byte instructions, but it's obviously far easier than having anything from 1 byte to 15 bytes. If you really don't want to do it then you're free to build a CPU without the C extension. All the tools support that. You just need to compile the software you need yourself -- or join a community of like-minded people.
Similarly if you want to modify ld to have an option to avoid instructions crossing 32 or 64 byte boundaries (configurable) then that's both pretty easy and I'm sure would also be accepted upstream. You wouldn't need to pad with a NOP or anything like that -- just leave one instruction in uncompressed form.
It really is the worst and most awful decision that RISC-V absolutely must retract, the sooner the better. We cannot have performance and compressed at the same time. There are other things about the C extension that make it extremely bad for emulators too.
The good news is that we can ignore rv64gc completely and just build everything rv64g, if you control everything yourself. Personally for my RISC-V use I actully do control everything and because of this I can pretend the C-extension doesn't exist.
I don't know if any of these have RISC-V support, but I would be interested in hearing about it. I would actually love a good distro for RV32G which is arguably a better match for FPGA softcores (and dev boards with > 4 GiB of external memory are rare)
On the other hand, there's a strong argument to be made that it's more difficult to make a RISC-V processor with comparable performance to a desktop-grade amd64 processor than to make an ARMv8 processor that with the same. (Personally, I'm a big fan of AArch64 being a fixed-width encoding, and both programming by hand in it and find writing assemblers and disassemblers is super-easy as a result.)