Many libraries are written to get things done or to support a particular programming style. Such libraries have their place in such a collection even when they shouldn't be standardized in any way (e.g. by turning them into a SRFI). One example is the λ syntax of Schemepunk. It is the same as the regular lambda except for treating (λ x e) as (lambda (x) e) instead of (lambda x e). This makes the behavior of λ rather irregular (so shouldn't go into a standard), but this doesn't mean that it shouldn't be published to used by those people who like this kind of idiosyncrasy. In fact, this may simplify some SRFI discussions when SRFIs can concentrate on those things where there is consensus and where no idiosyncrasies of a particular programming style are involved because everything else could be moved to the proposed collection of libraries.
Great point. Indeed, a practical library collection should be convenient (within reason).
This also give snew insight into SRFIs. Maybe they would best serve the role of building blocks or internals. Convenience and presentation is somewhat fickle and subject to taste. But the internals have to do with efficiency and reliability.
For example, a heap SRFI could provide the essentials that are needed to make a fast and space-efficient heap in a portable way, and others could provide the convenience procedures on top. This would also make it easier to write SRFIs, since good "engine" primitives are easier to understand than the totality of all use cases and what is convenient for each of them.
Classic SRFIs like 1 (list library) and 13 (string library) are an argument in the opposite direction, and John in particular has followed this precedent in his SRFIs, but all these SRFIs have been written in a time where Scheme doesn't have a de facto standard light process so there wasn't the option to make any kind of standard any other way.
