Thanks for a thoughtful review.

> 1) Because the term "fixnum" means something different in R6RS and
> R7RS-large, namely an exact integer whose smallest range is 24 bits and
> whose largest practical range is 63 bits at present, I think it should be
> avoided here.  Rather, the term "ASCII codepoint", analogous to "Unicode
> codepoint" should be employed.  This would be defined as an exact integer
> in the range 0 to 127 inclusive.

Not guaranteeing they are fixnums is a bit problematic because the
library mixes integers and characters freely (the offset arguments to
the transformation procedures; and accepting integers in place of
characters). The offsets can be arbitrary fixnums; for example, the
following maps ASCII to Unicode Mathematical Alphanumeric Symbols:

(string-for-each (lambda (char) (display (integer->char
(ascii-lower-case-value char #x1D400 26)))) "helloworld")

In the R6RS code of the sample implementation, I use fx+ and the other
fx procedures for arithmetic and comparison.

> 2) Remove all the repetitions of "char can be a fixnum or character object"
> and put it at the top:  "Unless otherwise specified, char can be a fixnum
> or character object" once and for all.

OK.

> 3) The remaining uses of "fixnum" in the section on transformation
> procedures should be changed to "exact integer" or "exact non-negative
> integer" as appropriate.  All other references shold be changed to "ASCII
> codepoint".

Since R6RS has fixnum-specialized arithmetic procedures, I'd like to
make sure people can rely on using them. They blow up (exception) on
bignums.

> 4) The sentence "The first ASCII standard was published in 1963" refers to
> a character encoding incompatible with today's ASCII.  Leave it out or
> change it to "The present ASCII standard was first published in 1967."

Good catch. Will change.

> 5) Add predicates ascii-codepoint? and ascii-string?.  The latter will be
> very valuable.  ASCII strings should not be a disjoint datatype, but simply
> strings containing ASCII characters only.

How would `ascii-codepoint?` differ from the current `ascii-char?`?

I think it's a bit dubious that the current `ascii-char?` doesn't
recognize an integer argument as an ASCII character. I was never
entirely happy with it.

> 6) Change the name of ascii-space-or-tab? to ascii-horizontal-whitespace?.
> This term is heavily used in RFCs.

I like the term "horizontal whitespace" and have used it in many of my
own programs (as the abbreviation "horz-white"). But I think the name
"ascii-horizontal-whitespace?" is far too long; hence it should remain
"space-or-tab?" or be abbreviated somehow.