PS SRFI 97 is obsolete anyway when it comes to R7RS systems. The new
naming scheme does not include, for example, a plural "s" in the
second part of the library name. This, actually, is an argument in
favor of the SRFI process I have proposed because a new SRFI can
easily overwrite and change these fundamental things, which a simple
database cannot.

Am Fr., 31. Juli 2020 um 11:17 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Fr., 31. Juli 2020 um 10:59 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
> >
> > There's a registry in SRFI 97: SRFI Libraries.
> > <https://srfi.schemers.org/srfi-97/srfi-97.html>
> >
> > As that SRFI shows, things get a bit messy. The document lays out
> > guidelines for what to do in the future about new entries, and added a
> > post-finalization note last year about the fact that the names are now
> > tracked in an S-expression file in `srfi-common`.
> >
> > IMHO this document illustrates the fact that the SRFI process is not
> > geared toward publishing evolving lists, though I agree that finalized
> > documents are great for archival.
>
> Please note that this is not the process I have proposed. Instead of
> adding to some not formally archived data file, a new version of SRFI
> 97 would have been published (say with each iteration of R7RS-large),
> obsoleting the respectively previous one.