They're working on this right now. Niche applications can still do their thing, but there will be standard profiles for e.g. a "Linux class" application processor, or an "ARM Cortex-M*" equivalent micro-controller.
Did a quick search on this, and I believe the Linux portion of this is the responsibility of the "UNIX-Class Platform Specification Task Group" [1]. They seem to be quite active, which I'm reading as a sign things are progressing.
RISC-V International is sometimes really bad at communicating that it's working on these problems. But odds on, they usually are.
Think of it like this: the difficulty of targeting RISC-V increases with the square of the number of variants.
It's a general rule in systems that difficulty and bugs increase exponentially, not linearly, as complexity increases.
What do you think `RV64GC` is?
RV64GCV, RV32IMAC, etc are all short-hand describing the supported capabilities of a given RISC-V CPU.
ARM has different specs for each type of core. https://en.wikipedia.org/wiki/ARM_Cortex-M
Compilers have handled this for years.
Hardware enumeration IMO can be harder than dealing with ISA variations. (And to my knowledge, RISC-V hasn’t solved any hardware enumeration problems.)
So if the CPU runs into an instruction that it doesn't understand, this will trigger a missing instruction trap and software can implement the instruction. Fragmentation problem solved, no?
Fragmentation is in general horrible. It was a major problem with ARM32, and that was much more strictly defined with less variation. ARM64 tried to define things more rigidly and has mostly banished the problem. The ARM ecosystem continues to be held back though by fragmentation around bootstrapping, hardware enumeration, and other aspects of the system that surround the core. Every ARM board tends to be a special snowflake.
I can't imagine RISC-V beyond niche applications unless someone publishes a more strictly specified version of it that provides a unified platform.