I understand you might be excited about a new type of W3C specification :P but I think definitions here should be ones we all agree on and which are implemented interoperably, not things that are registered by a UA acting on its own and are excluded from W3C RF patent obligations.

For a given OS, whether or not system-ui or system-sans-serif exists and what font it corresponds to is an answerable question, and it should be answered the same for all UAs on that OS.

Similarly, we are requiring that if a sans-serif font or serif font exists on the system, one must be mapped to that keyword.

If you want to argue that we should extract the list of font keywords into its own spec, I might entertain that notion. But I'm not convinced that it should be a registry rather than a REC-track standard. Registries are for things like mappings, not for normative definitions of things.

I agree with @fantasai. I don't see any reason to deviate from the existing process regarding these generic font families. I believe the current system solves all the desires listed in the bullets of #4566 (comment).

To me, the interest in the registry is more for things like fangsong and possibly nastaliq than for serif or ui-serif (which do have some degree of must associated with them): there's a good chance that we'll need more of them to support the needs of i18n, and they'd typically be described without any must or should beyond what the property definition already says: "The blah family corresponds to the ??? typographic tradition of the ??? writing system". Also, given that there's a very graceful fallback, I'm not sure I'd require/expect every UA to support all of them. I wouldn't want to block fonts-4 from REC because of an insufficient number of implementations of (for example) nastaliq. Or, less theoretically, of fangsong. Even if we did, for any given such font, there isn't really an observable difference between supporting it but not having a relevant font at hand vs not supporting it.

Once the mechanics of the font-family property are established in the REC track spec, the actual long tail of generic family names feels more like a list of well known names than like normative spec text.

If the list probably won't change and will stay as it is now, no need for anything new. I suspect it will grow (given that it already has started growing, and there we have requests for more), and so a separate document probably does make sense to avoid tight coupling between the release cycle of the mechanics parts and the font-list parts of css-fonts-4.

Now, if we all agree that the minimum requirement for being in that list would be two or more implementations, we can keep it on the REC track. But I suspect the bar could be a bit lower than that, and that with even with a single vendor interested in a value, ensuring non collision and non duplication, as well as giving the css-wg and i18n an opportunity for feedback could be enough for our purpose, even though it wouldn't be for REC.

Wait a moment, according to my limited understanding fangsong and nastaliq seems to be something totally different from other proposed font families?
For things like Nastaliq for arabic script, Fraktur for latin script, Small seal script for han script, they all seems to be different writing system variants of the same family. It will probably be better to handle them with the help of ISO 15924 where some of them are either already registered or will probably be eligible to register in there.
On the other hand, for things like Fangsong for Chinese, Kaiti for Chinese, or Marugothic for Japanese, they will probably be more appropriate for font family registry.

They are the same writing system. Same unicodes.

Related: Font styles & font fallback