[DESIGN] registry maintenance

[aphillips]

Capture for discussion the general ideas for how to organize the registry in the post-45 time period.

Notably, @sffc mentioned number skeletons in a comment on #621:

Note: My original idea from 5 years ago was that MF would use number skeletons and then become the specification that defines number skeletons since they are currently specified only in the ICU documentation.

This goaded me to write down some of the concepts floating around in my head about how to manage the registry going forwards.

[macchiati]

I like the direction. There are a few sections that remain to be filled out (eg What properties does the solution have to manifest to enable the use-cases above?
). Approving, assuming you want to go ahead with this, and flesh out more later.

[sffc]

Thought: should these "RGI" functions be prefixed in some way, like a vendor prefix, draft prefix, etc? For example, the definition of :person might need to change over time as more environments adopt it. Perhaps it should start as :person:draft or :person:2024a or something like that, only being promoted to :person once the design is finalized.

[aphillips]

RGI functions could be prefixed, but I think they are meant to pollute the common function namespace. We have :u namespace reserved below. The natural order of progression would be:

• :u:person <= early days proposal, leads to:
• :person "RGI" <= implement this if you wish to, leads eventually (maybe) to:
• :person <= implement this if you want to claim you support MF2

[eemeli]

This should also include options, so that e.g. :number skeleton could be specified, but would not be required.

[aphillips]

This was my intention. I'll add text.