Expressed a different way, my take is that non-"must" clauses of an RFC should be cleanly severable, i.e. you could literally cut them out of the document and e

Expressed a different way, my take is that non-"must" clauses of an RFC should be cleanly severable, i.e. you could literally cut them out of the document and everything else would still make sense. How a full implementation handles interoperating with an implementation that declines an optional feature should be defined in the same place as the optional feature. Further, being able to interoperate with an implementation that declines an optional feature should be required at the same optionality level as the optional feature. It shouldn't be a "must" to support interoperability with an implementation that has declined to implement a "should". This has basically the same effect as pushing optional parts into extensions. There's the core RFC that defines the spec, and a bunch of optional features that two implementations can use by mutual agreement. To address some common concerns about the effect this would have on general interoperability, keep in mind that a clause that reads "In scenario Foo, implementations should do X and should not do Y, but may do Z" can be much more cleanly expressed as "In scenario Foo, implementations must do X or do Y or do Z".