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. This, however, would need to attach some state to the supplied port to become a full replacement for the builtin `read': If `read' first processes the input `#!fold-case foo' and then the input `foo' from the same port, it has to return the symbol `FOO' on both invocations. Thus, the state whether the next read will be case-folding or not has to be attached to the port.
Using a weak hash-table to memorize this state is a fragile solution. As soon as there is a procedure like `duplicate-port', it would break.
The upshot is that Scheme textual ports should expose the current state of reader flags (they have to exist internally a well). I would suggest using symbols to name the flags so that the interface can be easily extended (e.g. by Larceny). The interface could look like this:
(port-flag port name) ; return the value of the flag `name' on the port `port'
(port-set-flag! port name value) ; set the value of the flag `name' on the port `port' to `value'.
If an implementation supports a reader directive like `#!fold-case' or `#!r6rs', their state has to be reflected by the above procedures. Setting a flag may alter other flags. For example, after `(port-set-flag! port 'fold-case #t)', the expression `(port-flag port 'no-fold-case)' will evaluate to `#f'.
This interface should be enabled for any textual port. It is relevant for the reader but not for the specific implementation of the port (in the sense of this SRFI), so it probably should go into a different SRFI. Nevertheless, it is no less important.