> Now that we have a concrete example and an explanation, I'll offer this
> counterclaim:  SRFIs don't have to be "substantial" in the sense of
> defining lots of symbols.  Consider SRFIs 2, 8, and 243, each of which
> defines just one symbol.

Agreed. Substantial work doesn't take lots of symbols.

I'm very happy with SRFI 193 which solved an important problem using
only 5 procedures. SRFI 175 (ASCII) had lots of procedures but was
neither substantial not mature; in retrospect, I abused the process.

SRFI 8 is a great example of something useful yet minimal.

> As for "mature", nothing starts out mature;
> everything has to go through a maturation process, and that process can
> happen on a SRFI email list as well as anywhere else.

IMHO the fatigue (experienced by insiders), confusion and alienation
(experienced by outsiders), and frustration (experienced by both) during
the past 3 years conclusively proves that SRFI is not the right forum
for immature proposals.

SRFI 18 and syntax-case are very complex subsystems that matured outside
the SRFI process in an academic environment. That's why they succeeded.

> I kind of regret that I have spent so much time writing complex SRFIs,
> which give the impression that if something is not complex it's not
> suitable to be a SRFI.  I have also focused on R7RS-large "batteries"
> stuff and not written any SRFIs that are only for specialized use,
> though
> https://github.com/johnwcowan/r7rs-work/blob/master/RoleBasedAccessControl.md is a pre-SRFI that was never intended for R7RS.

The "batteries" metaphor can unfortunately give the impression that
libraries are interchangeable components which are simple to plug in.

I finally know how to solve the "libraries" problem, but the solution is
novel and does not fit into SRFI or any other design process I've seen.