>     SRFIs are not the right vehicle for exploration.
>
> On the contrary, that is exactly what they are for.  See
> <https://srfi.schemers.org/about.html>: "We write concrete, detailed
> proposals and sample implementations for libraries and other additions
> to the Scheme language, and we encourage Scheme implementors to adopt
> them."

Nice misdirection.

If SRFI is for exploration, why are the least exploratory SRFIs the most
successful?

Why do the most exploratory SRFIs have the most problems?

Why are those problems so predictable?

Why do the problems seem to proceed directly from the structure of the
SRFI process?

Why would changing the structure of the process make the problems go
away? After all, nobody's complaining about exploration in Chicken eggs.

Why does cutting out the exploratory parts of a SRFI solve that SRFI's
process problems?

>   A proposal is a suggestion, not a specification.

The meat of the document is literally called "Specification". The whole
problem is that we so often specify something we don't understand.

The salient question is: Why's it so difficult to hold up a mirror to
our methods?