> 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.

Any thoughts on this? If people are sympathetic could try to draft a
fairly precise partitioning of SRFIs to have some details based on which
to continue discussion.

The 60-day deadline for SRFI 170 is at the beginning of July so we'd
best set the general course soon.