The Imperative I/O layer of SRFI 68 already deviates from R5RS in some
aspects, such as the absence of a distinct EOF object.  Taylor
Campbell has suggested making the naming more regular, which would
rename a number of identifiers from what they are in R5RS.

This raises the general question of how important R5RS compatibility
is in this area.  My own personal sense is that most I/O-bound
programs aren't portable anyway, because R5RS doesn't provide near
enough functionality, so they have to resort to
implementation-specific abstractions.  (Moreover, a R5RS compatibility
layer would be trivial to implement on top of SRFI 68.)  This would
imply that R5RS compatibility shouldn't be a primary concern here.

It'd nice to have some sense of what the community thinks on this
issue---any input would be much appreciated.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla