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.
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.