I/O is where programs meet the real world, which is not as
elegant and consistent as we wish.  It is inevitable for
the I/O library to bloat if one wants to support any possible
situation that may occur in the practical applications.

However, I wish I/O srfi to allow implementators to adopt
features selectively, and gradually from the infrastructure
they already have.   Splitting former srfi-68 into several
srfis was an important step towards that and I appreciate
the author's effort.  And I especially like that the port
layer no longer assumes the stream layer.

At this point, if I were to adopt some of those srfis,
I would take only srfi-81 (the Port I/O).  For the
implementations that already have extended port features
such as block I/O, file positions, and customizable
I/O routines, srfi-79's readers and writers adds little value.

The layering of reader/writer and port/stream is fine
for a design of a new I/O subsystem of a certain
implementation.  If these srfis are to be common API among
various implementations, however, they should be designed
so that the existing implementations can naturally extend
their features towards these srfis.

So, as far as the common API is concerned, I'd suggest to
make design discussion top-down (from the port layer) instead
of bottom-up (from the reader/writer layer).  Let's find
a port APIs that can be implemented efficiently on various
implementations' native ports.

I'll comment on srfi-81 later...

--shiro