> I would say this is the biggest problem with the SRFI process.  In the SRFI process a proposal is made, discussed and changed in a mostly academic fashion with typically minimal implementation and usage experience.  A SRFI would be much more valuable if it was a design proven through some amount of practical use to “debug” the design and iron-out the details.  If a new “more lightweight” process is created, it could feed the SRFI process and also stand on its own (some contributions are really more RnRS libraries that don’t need to become SRFIs if they have a documented API).

Exactly! Parts of the fast-moving library collection that have been
stable for a while (e.g. 1-3 years) could then be submitted as SRFIs.

Of course, SRFIs can still be submitted while the process is ongoing,
but the SRFI process would now be freed to focus on problems that either:

1) tie heavily into implementation details (e.g. FFI, threads)
2) deal with core language stuff (syntax, threads, continuations)
3) are well explored and have converged on a well understood solution

> As I have argued in the past a decentralized library/package management system that is supported by many Scheme implementations could serve this purpose well.  It is “decentralized” in the sense that the libraries are stored and maintained in web-accessible user created repositories (github, gitlab, …).  This does not preclude having a centralized “library aggregator” that lists all of the available libraries with their URLs.

This is essential as well, but orthogonal to the problem of design process.