> We may need further registries, for example for standardized feature
> identifiers that extend the small list in R7RS-small.

Yes. I have some sketches at
<https://github.com/srfi-explorations/identifiers> - just simple
S-expression files.

> I would have proposed to use the SRFI process for it. Whenever there
> is a major change in the registry, an updated SRFI (only containing
> that registry) is issued while the previous version will be withdrawn.
>
> I think it is simpler or safer than inventing a new process, whose
> life may depend on the lifetime of the git repo chosen.

Very interesting and novel idea.

I like it from an archival point of view, in which it is indeed
reliable. The only thing I worry about is that it would generate "noise"
in the SRFI process:

- How often would a new registry SRFI be published, and where would new
submissions be gathered in the meantime?

- Scheme implementations typically claim that they support particular
SRFI numbers. What (if anything) should they say about which registry
SRFIs they support? It they list all of them, it would cause a lot of
new identifiers in (features) and (cond-expand) over the years. Perhaps
such registry SRFIs should simply be omitted from the (features) list.

If the git repo is tied to the SRFI process, it would be safest to have
a policy of storing it in the same place as the other SRFI repos. In
fact, perhaps they could be stored as S-expression files in
<https://github.com/scheme-requests-for-implementation/srfi-common>.
Arthur already has scripts to generate HTML pages out of data files in
that repo, so perhaps extra page(s) could be generated for the registry.