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