R6RS has nothing to say about character buffering as opposed to byte buffering, and seems to have been written as if it doesn't exist.
Without character buffering this should automatically be correct. I also think that implementations should not even byte-buffer custom ports, though probably some do.
The problem occurred to me when I wrote my syntax expander for R7RS. First, I couldn't use R7RS's `read' procedure to implement `include-ci' because there is no way to portably tell the builtin reader to read, say, `#\Space' as `#\space'. Thus, I had to write my own `read' procedure.
Okay, I see why that's necessary. It is irritating; it would be better if there were a resumable exception that lets a caller define what #\iota means rather than relying on the implementation. It also means, for example, that if a system supports both #\Alpha and #\alpha (in the way that HTML defines both Α and α), the distinction is lost when reading case-folded. Presumably legacy code would not make use of such escapes, however.
This, however, would need to attach some state to the supplied port to become a full replacement for the builtin `read':
I talked to the Chicken people about this, and they don't see any reason why case-folding has to be port-specific. In Chicken case-folding is a parameter that is globally visible, but only `read` normally makes use of. While this approach is not as theoretically neat, I think that the situation of reading S-expressions concurrently from two sources that don't agree on case-folding is vanishingly rare in practice. Certainly it is not needed to support include-ci, as reading from the included port is strictly nested.
Chicken also has global parameters to treat [] and {} as parentheses, to support either :foo or foo: as a keyword (#:foo is always a keyword), and to support or not support symbols in vertical bars (which technically might have other uses in R5RS code).