>     I am neither for nor against partitioning the SRFI.
>
> I can imagine arguments in both directions, e.g.:
>
>   * The sub-problems Lassi lists are largely independent, so splitting
>     the SRFI into several SRFIs, one for each, would make it easier to
>     make progress in parallel, perhaps taking the burden off of John to
>     do the whole thing.
>   * On the other hand, there are certainly concerns that are common to
>     all of the sub-problems, e.g. how low-level the API should be and
>     how closely it should map to POSIX APIs vs. other APIs.

In my opinion, the best of both worlds would be to have reasonably
fine-grained partitioning of SRFIs but write them all in parallel so the
same design effort can address them all.

The partitioning could start by thinking about (import (srfi ...))
expressions -- a natural unit of code of that makes sense for someone to
import would mean good SRFI boundaries. Another test is whether it makes
sense to for a Scheme to implement functionality A without functionality
B. If it does then A and B could go into their own SRFIs.

Some immediate observations:

* For things that only work on Windows, it's natural to (import (srfi w)).
* For things that only work on Unix, natural to (import srfi u)).
* For things that work on both, (import (srfi b)) is clear.
* It makes sense to support a file system without also supporting
networking.
* It makes sense to support subprocesses without supporting terminals.
* It doesn't make as much sense to support subprocesses without
supporting signals, because signals come up when waiting for
subprocesses (they can be terminated by signal, or stopped and
continued, or the parent process can signal them to terminate, etc.)
* etc.

> It's up to John and whoever else volunteers to do some work on the one
> or more SRFIs to decide.

I can volunteer to write or co-write SRFIs if that is an impediment.