Why though? We don't expect that of X86, ARM, or anything else. X86, ARM or the hundreds of other ISAs that have come and gone. We don't ask because it's impossible without putting a freeze on adding new instrucions. Once you add a new instruction there's no way for binaries with that instruction have that instruction run on an older processor. A compiler reads a value from memory. If that value doesn't map to an instruction it can follow, what do?
RISCV is actually better than most in this. First of all there is a core ISA that will run on everything and the extensions can be setup to be ignored when running on a system without them, defaulting to some core-ISA alternative.
The only alternative is to get the entire ISA spec done before letting anyone make anything... and that's just not happening.
One would simply specify that for any instruction used by a binary outside some core set, a fallback must be offered. For many instructions, the fallback might be just a few bytes of code.
The hardware would provide some assistance for said fallback mechanism - for example in the form of a pointer to a "fallback vector". If you execute unknown instruction 0x80 then code at the fallback pointer+0x80 will be executed instead.
The binary doesn't have to use this fallback mechanism - for performance critical binaries which want to run fast on different hardware implementations, the compiler could use feature detection to make multiple implementations of some functions, the way many SSE/AVX extensions are dealt with in the x86 world.
Binaries that aren't intended to run on bare metal, but instead run on some OS (eg. windows/linux) could instead specify as part of their ABI which instructions are part of the core, and the OS will ensure that anything unsupported by the hardware but required by the binary will be provided by the OS.
Almost everything here is outside of the ISA-spec's scope though. Mandating a fallback-vector be specified for each compilation and there be compatible alts available there seems like you're going beyond an ISA spec and into how programs and data are stored. Sure, RISCV could say "here's what you run instead of new instruction Y if Y ins't available but I'm not sure it's in there remit to ensure these alt instructions are always there.
Your comment about the compiler using feature suggestions has got nothing to do with RISCV, it's up to the compiler developers how to do that and if they want to. This is how it works right now. The compiler inspects the hardwarew and works accordingly.
RISCV dont get to decide how the OS works. It's up to the OS developers on how a binary is handled. They can't stop me creating an OS that doesn't filter unsupported instructions and therefore the guarantee cannot be kept.
You could have an interrupt style thing for unsupported instructions with suggestions on how software/the OS handle them, but whether or not they choose to handle them is not RISC-Vs problem.
> One would simply specify that for any instruction used by a binary outside some core set, a fallback must be offered.
That is exactly what RVA23 does. It specifies what must work. It doesn't specify the performance of any instruction -- that is between a hardware vendor and their customers as to which ones are fast.
> If you execute unknown instruction 0x80 then code at the fallback pointer+0x80 will be executed instead.
RISC-V instructions are 4 bytes long (i.e. 2^32 of them), not 1 byte. Using that simple technique, with just a pointer to the actual handler included in the table, the table will be 32 GB in size.
RISCV is actually better than most in this. First of all there is a core ISA that will run on everything and the extensions can be setup to be ignored when running on a system without them, defaulting to some core-ISA alternative.
The only alternative is to get the entire ISA spec done before letting anyone make anything... and that's just not happening.