> 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.

Right. But then you'd get many (for example, yearly) differently
numbered versions of SRFI 97. Not such a big problem on 1-2 a year
timescale, but it adds up over a decade.

> PS SRFI 97 is obsolete anyway when it comes to R7RS systems.

But R6RS is not obsolete; it's a parallel version of the language. It's
a matter of taste whether it's better, worse, or equally good as R7RS.

> 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.

One of the main virtues of a Scheme registry would be to help keep a
stable set of identifiers instead of coining new names for the same
things in new standards and implementations.

Hence changing the identifiers in new versions of the registry SRFI
would be a misfeature IMHO. If particular identifiers truly are broken
for some technical reason, new alternatives could be added, but the old
ones should still be kept.

Of course a new set identifiers of can be coined where it makes sense
(if the old set had some kind of fundamental design error discovered in
retrospect), but quite often people invent new things simply due to not
being aware of or familiar with existing things. This can be NIH
syndrome, or simply too much information not organized well enough.