>SRFIs only really turn into endorsements once the implementers adopt them.

Indeed, but an SRFI is the first step to adoption of something.
(Which, in my opinion, should be discouraged rather than adopted.)

>I'm happy to have both!

Again, I am no expert, so I can only state my opinion that (it is one
of those extremely rare cases that) having neither would be better
than having both.
(Since each user would have to implement such simple code from scratch
if needed, and thus bear full responsibility for the
incompatibilities, which will be unavoidable either way.)

On Thu, 11 Aug 2022 at 15:53, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> > Another noble goal might have been to "do an extensive research and to
> > create an exhaustive model for INI files for everyone's reference".
> > But this srfi does not seem to have such a goal?
>
> Exactly. An INI SRFI that doesn't require the user to specify which
> flavor of INI to use will standardize subtly broken code.
>
> Surveying the extant flavors is tedious, but it's the right thing to do.
> And would help communities beyond Scheme.
>
> Here's a typical manifestation of the problem:
> https://github.com/editorconfig/editorconfig/issues/97

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)