> Since you don't mention any problems with the monorepo approach I assume
> it has been a success. If that's the case, it's good to have validation.
>
Gerbil hasn't scaled to enough users or contributors to call it a
success. But at least it's not a failure.

Right now, I would say that the high barrier to documenting and
testing is a pain.

Ideally, we'd be able to do literate programming of the code + doc +
tests. But that's work.

>> A lot of things could be done to make Gerbil nicer, more portable,
>> more coherent, etc.—but it's a great starting point.
>
> Like Racket, Gerbil adds quite a bit to standard Scheme. How much of the
> current Gerbil libs would run on standard Scheme (R6RS and/or R7RS) and
> would Gerbil users be interested in collaborating on a standard Scheme
> library collection?
>
Gerbil would require bootstrapping on top of those various Scheme
implementations. The current version of Gerbil is quite tied to Gambit
Scheme for all I/O or lower-level functions.

Gerbil *could* be ported to other Scheme implementations (and was, in
the past). But in a way, it would not be a "standard Scheme library
collection", unless you somehow hacked the library systems to become
interoperable. I'm not sure if that's possible in a portable way, but
identifying the gap would be interesting—and could lead to a SRFI for
extending the library system that way to make that possible.

> I have a strong interest in all the interfaces being portable to every
> reasonably featureful Scheme that wants them, and so far others feel
> similarly. The code itself can be cond-expand'ed as needed.
>
cond-expand itself doesn't work very portably, does it?

—♯ƒ • François-René Rideau • Co-Founder and CEO, MuKn.io
It's better to know nothing that to know what ain't so. — Josh Billings