I am not really saying spec changes are required. I am making a suggestion for a different way to consider the specs and to maybe add an additional mechanism (e.g. JSON Schema’s). But how this is done exactly should be in a discussion between current implementers fased with bad DX, thinking of the needs of future implementers that love fedi’s DX 
Nice. I like it. Friendlier-sounding. Cross-ref to “What is our own Domain?” topic and related SocialCG issue.
“Extension” is the word we currently use without clear definition, and for sure can find better terminology. When I say “extension” I refer to “AP extension” which is any combination of vocab + behavior. Wrt behavior I often mentioned “msg exchange pattern”, but if you have some vocab extension e.g. additional properties, then they may also be subject to having particular business logic associated to them.
In that light I don’t think it is valuable to distinguish between vocab-only extensions and behavior extensions. And extension is an extension… one might say: given that the protocol is pluggable, extensions add additional specs for particular use cases. Hence by definition they extend the spec. You must take them into account to interoperate with an extended endpoint. But a whole different terminology may be chosen.
So given the definition above, this is an extension (to the spec) even though it may restrict the behavior of the endpoint.