> As the example of make-coroutine-generator shows, it is not only about
> breaking interfaces.  For another example, consider the comment about
> vector-sort! in SRFI 132.  It says that no O(n log(n)) algorithms
> running in constant space are known.  Suppose, miraculously, someone
> found such an algorithm and a simple one on top.  So we would like to
> amend SRFI 132 with this extra guarantee.  This would not justify a
> whole new SRFI, but a bump from version (1 0 0) to (1 0 1), say.

SRFIs are not the right vehicle for exploration.

These problems are predictable. I put great effort into trying to get
people to take them seriously in the context of R7Rs-large. It didn't
work. I still don't entirely understand why, given that the problems are
amply demonstrated and alternatives are readily available.

Since RnRS is being over-engineered, and it is based on SRFIs, it's
natural that the SRFI process would eventually face the same
over-engineering pressure as well. I failed to anticipate this. I've
given up on getting RnRS back on track, but please, let's preserve SRFI.