>>> Especially if you want to permit mistakes/erroneous decisions?

> This is not forbidden by the SRFI process to amend with PFN a SRFI, or
> supersede with another SRFI.

Yes, SRFIs can be rewritten but it's somewhat costly. The thing is that
for many problems we have started writing SRFIs without a clear idea of
the problem domain, which is the main reason we haven't kept to the
90-day deadline in the SRFI guidelines.

The solution is to do most design work using a lightweight process, and
only submit the result as a SRFI once it is stable. But we don't have a
standard lightweight process; everyone has been doing their own thing,
often by themselves. https://github.com/pre-srfi goes a step toward more
collaboration, and has been a success, but each draft is still siloed up
in its own repo and there's a sense that the person who first wrote the
draft owns it, with others commenting in issues.

I expect that we'd get things done faster with better morale if we went
a step further to use a monorepo with collective ownership.

> The problem I see with R7RS is there is
> no standard test suite outside Chibi, which requires an advanced
> implementation to make it run. The SRFI process has no dedicated
> Scheme implementation officially, Chibi will not be the best choice
> for the long term.

Agreed. https://github.com/srfi-explorations/srfi-test was and is an
attempt to fix that.