>> So I suggest to keep encoding directive simple, parsable with a small
>> finite automaton without lookahead.
>
> Agreed.

There was a long discussion about encoding declarations in this thread
(or another thread that went on at the same time on this list) that
covered all the angles.

Anyway, also agreed. A #! directive can occur anywhere in a stream and
make sense there. It would be easier to understand if we have no
#!encoding directive at all; if we do, then it can occur in the middle
of a REPL session and the implementation will have to change its
encoding on the fly. And the #!encoding declaration itself will have to
be encoded in a way that is compatible with both the old and the new
encodings (not a problem for encodings that are ASCII supersets, but a
big problem for others).

In practice, unless there has been an encoding error in some file,
encodings should not change mid-stream (or mid-REPL). Well, I can't
think of a case where that makes sense. There might be one.

Other alternatives:

1) A declaration at the start of a file (Gauche and Kawa read
Python-style encoding: magic comments at the top of the file).

2) A declaration in a separate metadata file.

3) A command-line flag for REPL and script use.

4) A set-port-encoding! procedure to change the encoding of a textual
input port mid-stream.