What is your practice going to be in maintaining the ‘library name’ field in the SRFI metadata now? Some libraries have conflicting names now. Shovelling implementation decision onto ‘implementers’ in the case of a SRFI about SRFIs is irresponsible and will put implementers off entirely in the presence of confusion such as this.

On 8 Dec 2025, at 06:06, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

> I understand that you believe that it is an "inadequate design specification," but that is a matter of opinion.

The SRFI process gives you the explicit power to reject SRFIs with such inadequate specifications.

> Surely you're not suggesting that the way to propose a general change to the naming conventions used for SRFIs is to make a separate SRFI for each proposed name change.

No, a single SRFI proposing a complete new registry with all-new name assignments would be fine. But it would have to be explicit that establishing a new and separate registry is what it intends to do. SRFI 261 has not made its intent clear here, and appears to be overriding existing assignments in an existing registry.

But it would be preferable, as I mentioned, to not have treated SRFI 97 as precedential. It would be better all around to have a separate process for discussing changes which affect SRFIs on the meta level and in general, rather than allow just anyone to come along and muck around with retroactive changes.

>>  I have lost a tremendous amount of faith in the SRFI process because of this.
>
> I am sorry to hear that.  Perhaps that's because you still don't understand the basic idea behind the SRFI process.  I'm not sure how to make it clearer.

This is, frankly, insulting to my intelligence and a gross misrepresentation of my position, and I am disinclined to continue working in the SRFI process if this is your attitude.

Daphne