Formalizing the role of extensibility as launch pad for future XLIFF Core or Module features

I propose we formalize a concept we've spoken of robustly at TC meetings: Extensibility is the prescribed method for candidate Core or Module features on the way to becoming officially supported by XLIFF.  I think we should put this in an official note (but if putting it in the spec is better, so be it).  I think we should create a TC sanctioned and maintained XML catalog to manage namespaces used for this purpose.  Today we have our official XLIFF namespace catalog:
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/schemas/catalog.xml
Which we describe in the 2.0 spec:
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html#xml_catalog
I think we should create a cousin catalog that hold names and schema URIs, along the lines of:  <?xml version="1.0" encoding="UTF-8"?> <catalog xmlns="urn:oasis:names:tc:{add some name here to indicate these are candidate features}">
<uri name="myurn.candidatefeature.mygreatfeature" uri=" http://myplace/schemas/mygreatfeature.xsd"/ >
<uri name="myurn.candidatefeature2 . . .
<uri name="myurn.candidatefeature3 . . . </catalog>  Requirements could be put in place to protect us from frivolous entries (must be a valid schema; must remain accessible; must not compete with existing XLIFF feature, . . . ).  We spoke of this a bit at the last P & L meeting. If I'm leaving out points, please add them.  Thanks,  Bryan