I am about to embarrass myself by asking two stupid and naive questions. But it feels like time for one of us who is not strongly involved emotionally with one side or the other of this issue to do so. It seems to me that "site local" is actually two different things:
(1) A set of semantics and expectations about, e.g., applications behavior, otherwise known as "the feature". (2) An address range.
Is that correct, or is that controversial too?
Now part of the justification for IPv6 is to have "enough" address space. We may be moving toward that being the only justification, but that is another discussion. "Enough" presumably includes sufficient headroom that we can make a mistake about allocation strategies and deal with it by simply retiring the block. One would not want to do that often, especially with large blocks, but we ought to be able to survive more than "never".
Given that, and given the argument that some important and hard-to-reverse decisions have been made that use that address range, is it plausible to:
(1) Remove, deprecate, or otherwise dispose of, the feature. (2) Permanently retire the address range so it is never allocated and identify it in the relevant records as "retired".
Now, we have pretty strong statements around to the effect that, if an address range isn't allocated, one is not supposed to use it and certainly isn't supposed to let it leak. One could even reinforce that with a statement/ standard/ BCP encouraging filtering the range, which would bring us more or less back to the 1918 situation (reserved space, no semantics). But an enterprise that thought it needed local space could presumably use that range, with appropriate filters, etc., but without assuming that, e.g., applications would treat it in a special way.
I don't expect this suggestion to make anyone on either side happy, but is it possibly a way out of the "you can't really deprecate that without causing worse damage" part of this mess?
john