> I've been inclined to write "source code encoding magic comment" srfi,
> which Gauche is using.

Do you mean lines like this: ";; -*- coding:utf-8 -*-" -- this is the
same syntax that is used by Emacs, right?

> Without it, using non-ascii characters in the source code may cause a
> portability issue.

This is definitely true, but seems less of a problem with every passing
year. IMHO mandating UTF-8 would be simpler than choosing from a variety
of source file encodings. Is there still a large user base writing
Scheme in other encodings?

> If there's a comment that matches a specific pattern at the beginning of the source, it can
> specify the file encoding

If there is a facility to specify the file encoding, could it be an
S-expression instead of a magic comment? Magic comments are a hack in
general and Scheme/Lisp macros let us easily add metadata as
S-expressions. Emacs Lisp recently added "-*- lexical-binding: t -*-"
comments now that is has lexical binding support. I don't understand why
they didn't just go with some Lisp form such as (declare-file
(lexical-binding t)).

In the case of "-*- coding: -*-" I understand that Emacs already parses
it so the compatibility is valuable. However, it's not parsed by Vim and
other editors (which have their own editor-specific magic comments).
There are less magic and more portable solutions such as `.editorconfig`
files (<https://editorconfig.org/>) which are also easily supported by
Emacs (just install the 'editorconfig' package from MELPA) and many
other editors and require no annotations in Scheme files.

`.editorconfig` files are not (and probably should not be) parsed by
Scheme when loading source code, but if encoding markers are put in
Scheme files I think a S-expression such as (declare-file (coding
utf-8)) would be cleaner than a magic comment. Does S-expression parsing
have problems that do not occur with comment parsing (e.g. when using
non-ASCII-superset multi-byte encodings such as UTF-16 or Shift-JIS)?