+1 on the SRFI.

Two issues strike me.

1. [Flushed with pride] R7RS defines flush-output-port; however, the
effect on that is unspecified with the current custom output port specs.
In R6RS, flushing either happens according to the buffer mode, or when
flush-output-port is called. R7RS does not provide buffer modes, so
flush-output-port is likely to be used more frequently. It's entirely
possible that a custom port might need to do something special when it
is flushed (e.g., refresh a screen region). I would suggest, therefore,
that a trailing optional flush argument be permitted. flush-output-port
will therefore call that procedure, or do nothing (if it's omitted or
#f). The semantics of flushing will of course be up to the custom port
itself. (A custom port might end up calling its flush procedure from
three places: in write! when line buffering, in close, and in flush.
That's its problem.)

2. [Bidirectional ports] R6RS defines input/output ports, whereas R7RS
doesn't. There are good reasons for eschewing them on files (the
semantics of a  port for randomly reading and writing a file---a
practice fortunately much more common in the Long-Ago than now---are
quite different from those of a port that provides input from and output
to a terminal). However, custom input/output ports would still be very
useful, with the issues of port semantics left to the port's designer.
I'd therefore argue for their inclusion as per R6RS, either here or in a
subsequent SRFI.

-- vincent