>> It would be really nice to avoid yet another Scheme file extension.
>
> Not every file containing sexpressions is a Scheme program, for which
> most (all?) R7RS implementations use the extension "scm". So it is
> actually not the best idea if a general file containing sexpressions
> and that is not a top-level program, has the "scm" extension. We could
> use the extension "sexp", but this may become problematic when it is
> truncated on 8.3 file systems. :)

Emacs Lisp files have the extension `.el`, and some packages use `.eld`
for "Emacs Lisp data" that is not loadable code.

There is not a similar convention for Common Lisp's `.lisp` extension.
CL data files tend to use the same extension I guess. We've been doing
that with Scheme as well, using `.scm` for data.

The trouble with a generic S-expression extension is that there are
different variants of S-expr syntax. The file would then have to stick
to a portable subset. (If it isn't portable, we should probably use a
Scheme-specific extension instead of a generic S-expression extension).

Personally I'm in favor of fewer extensions overall and deducing more
things from file contents instead. File name extensions are a hack to
begin with; file contents should ideally be self-describing. `#!r6rs`
and `#! /usr/bin/env fantastic-scheme` are two such useful identifiers.
Perhaps the  `meta.scm` file can start with `#!metadata` or something.
Would that be considered reader abuse?

I intend to separately propose a `declare-file` form that can go at the
beginning of an S-expression file and explain what kind of file it is.
But so far, nobody has been too excited about that either :)

>> Some people have a general dislike of dotfiles (e.g. many Go programmers
>> think they are a hack). They are also slightly problematic on Windows.
>
> Windows does not allow them?

Windows does allow dotfiles, but they look weird in Windows Explorer
(the file manager) and I'm not sure how file associations work (i.e.
whether ".scheme" would be considered a blank filename with a ".scheme"
extension or a ".scheme" filename with a blank extension).

> Anyway, in this case, I'd advice against
> as well because they are normally invisible but may contain important
> information (like library aliases) needed to understand the program.

Agreed.