> HTML has become (at least outside the W3C) a "living standard". If we
> can get such a model working for R7RS (large), it can be a huge step
> forward because whatever design mistakes we make now, we have a chance
> to correct later.

I've lately been thinking about the same thing. Library design is just
too hard. It boils down to that Perlis aphorism, "Programmers are not to
be measured by their ingenuity and their logic but by the completeness
of their case analysis." A library is at bottom just an abstraction of N
different use cases. The bigger N is, the better the library will be.

(At some point it will become over-engineered, but skilled designers can
push an abstraction quite far before it reaches the breaking point, and
it's perfectly possible to design over-engineered things based on a
small sample size.)

We've had success at SRFI design by pushing up N before finalization.
That has often uncovered hard-to-implement, hard-to-use or superfluous
design choices. Pushing the number of supported Scheme implementations M
has been helpful as well. A good Scheme library comes from a high M * N.

But since we are not gods, our sample size is inevitably too small to
account for everything, as it is for all other people too. The
unfortunate thing with Scheme is the dearth of actively developed
applications. Apps are needed to put library designs to the test.

> Maybe, this can be solved with library versioning.
> Unfortunately, R7RS (small) decided to use (scheme XXX) and the
> reddish editions of R7RS (large) have continued to use (scheme XXX) so
> all future standards have to use something more complicated (unless we
> define that (scheme XXX) is the "current" version of whatever library
> while the initial R7RS will only be guaranteed when accessed through,
> say (scheme XXX (7)).)

Indeed, library versioning would be the way to do it. I've been thinking
about yearly editions. Each new year's edition would start as a copy of
the previous year's edition, and then things would be changed as needed.
If a mistake is made, it can be rectified next year.

At all times, we would make sure that code using different years'
editions can easily be mixed. I.e. we would take care not repeat the
Python 2 vs Python 3 incompatibility mistake.

As for the specific naming, I guess (import (scheme char)) could be
(import (scheme char 2020)). R6RS comes standard with a library
versioning system, but it seems it hasn't gotten much traction.