Although there is surely a great deal to say about the content of this
proposal, I have not yet put enough thought to the matter to articulate
it.  However, Mike Sperber prompted me to send my initial thoughts on
some very minor naming matters to this list, so:

1. For the input routines, it would simplify things to conjoin the
   INPUT-BYTES & INPUT-BYTES-N, and likewise with the string input
   routines and the string & byte port readers, by simply making the
   count parameter optional to INPUT-BYTES.

2. A similar simplification could be made on OUTPUT-BYTES and
   OUTPUT-BYTES-N, &c.

3. END-OF-STREAM?, EOF?, EOF-OBJECT?: It would make more sense to me
   for EOF? to be renamed END-OF-PORT? to be consistent with
   END-OF-STREAM?, particularly since some Schemes already have an
   EOF? that is equivalent to R5RS's EOF-OBJECT?, and EOF? implies that
   there is a file involved, while there isn't necessarily one with
   ports.

4. I think it would be better to make the string stream/port names a
   bit more consistent with each other; to expedite this, here's just
   my suggestion for the whole set of operations:
      OPEN-STRING-INPUT-STREAM         OPEN-STRING-INPUT-PORT
      OPEN-STRING-OUTPUT-STREAM        OPEN-STRING-OUTPUT-PORT
      CALL-WITH-STRING-OUTPUT-STREAM   CALL-WITH-STRING-OUTPUT-PORT
   (Similar names would be used for byte vectors as well.)

5. It has seemed to be conventional for procedures named CALL-WITH-...
   to call their last argument with some value, such as a newly opened
   port, while WITH-... sets up something in the dynamic environment
   and calls the procedure passed to it with zero arguments.  This is
   how R5RS's four procedures with these name styles work.  Therefore,
   I think it would be better to use either WITH-CURRENT-INPUT-PORT or
   WITH-INPUT-FROM-PORT for what is CALL-WITH-CURRENT-INPUT-PORT in the
   current draft, and likewise with CALL-WITH-CURRENT-OUTPUT-PORT.

6. The names DISPLAY-CHAR &c. are inconsistent with both the symmetry
   of reading & writing and the terms 'reader' and 'writer' already
   used in the specification.  It is claimed that the term 'write' as
   used in names like WRITE-CHAR is inconsistent with the procedure
   WRITE, but so is READ-CHAR with READ.  The important part, however,
   is not the way the element is written but the invariance & symmetry
   between reading & writing of any sort: objects, characters, bytes,
   &c.  So it's more consistent to have READ & WRITE, READ-CHAR &
   WRITE-CHAR, READ-STRING/WRITE-STRING, et cetera pairs than to reject
   the term 'write' because of its use for the S-expression writer.