> Give me examples of all of these!  It's very easy to claim these things.

Come on.

It takes time to compile lists of examples, and it has been my
experience that people who are strangely unable to find their own
examples of known issues request them from others in bad faith. Here
they are. Will they be subjected to the same weaseling as my initial claim?

I do not enjoy debates. In my book they barely qualify as an
intellectual activity. I've been engaging the regulars in all this word
twisting about RnRS and SRFI in an attempt to get an answer to one
question: Why can't we put these institutions back on track? Pinpointing
the problems is not hard. Coming up with solutions is not hard. What's
really in the way?

Top tier people are put off by rhetorical misdirection. I am not a top
tier person but I certainly set a minimum bar, and these institutions
are failing to engage me despite my best efforts. You will simply not
retain anyone talented whose talent isn't about being detail oriented.
The lack of accountability and common sense is too flagrant.

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

1 (lists), 13 (strings), 69 (hash-tables), 98 (getenv), the sorting and
bitwise SRFIs.

18 (threads) was groundbreaking but had its exploration done before
SRFI, averting the process problems. The mail archive has only about 60
messages.

The R6RS SRFIs had their exploration done before they were submitted.
E.g. SRFI 93 specified syntax-case and received only 70 messages.

And SRFI 1, which isn't innovative, is still more popular.

>     Why do the most exploratory SRFIs have the most problems?

177 (keyword args, mea culpa).

170 (posix), and FFI SRFIs in general.

The array stuff (e.g. 122 had 15 drafts and was ultimately withdrawn).

Advanced formatting (159, 166 took more than a year each).

The (match ...) SRFIs.

The comparator stuff.

>     Why are those problems so predictable?

Missed deadlines, scope creep, discussions that go in circles, fatigue
with the volume of discussion, revisions and PFNs.

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

It's hardly surprising when 90 days isn't enough for a loosely organized
group of busy volunteers to do research.

>     Why would changing the structure of the process make the problems go
>     away?

Every Scheme package manager, for starters.

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

170 (posix).