Thank you for the informative review.

> 1) Typo:  s/expresssion/expression/

Fixed.

> 2) Cygwin supports both /proc/self/exe, a symlink to the executable, and
> /proc/self/exename, an ordinary file containing the name of the
> executable.  The first is compatible with Linux; the second is backward
> compatible with old Cygwin versions.

Added to the list.

MSYS2 is based on Cygwin so I assume the same method works there.

> 3) R7RS makes a threefold distinction between libraries, top-level
> programs, and scripts.  A library is a file containing a define-library
> form or a compiled version of it.  A top-level program is a file
> containing imports, definitions, and expressions, or a compiled
> version of it.  A script is also made up of imports, definitions, and
> expressions, but is to be passed to a REPL and executed/evaluated on the
> fly.  R6RS does not discuss scripts.
>
> This means that if `fantastic-scheme` runs a REPL, then
> `fantastic-scheme <foo.scm` runs a script in the R7RS sense, but not in
> the SRFI's sense. I suggest that the definitions be aligned.
>
> For the purposes of this SRFI, then, you are either running a
> (top-level) program or not; if not, you may be using an interactive REPL
> or running a script.  The program level of the SRFI makes sense only if
> you are running a program.  It can be invoked usefully from a file
> loaded from, included by, or imported into a program, but not from files
> processed by the REPL or a script.  In particular, typing (load ...)
> into a REPL should not count as running a program, since the loaded file
> may do nothing but add definitions to interaction-environment.

Aligning the SRFI's terminology with RnRS is definitely preferred.

R6RS non-normative appendix D is about scripts (in the Unix sense).
<https://api.staging.scheme.org/static/r6rs-app-errata-corrected.pdf>

I can't find any mention of scripts in R7RS-small. Is it in -large only?

By program level you mean command level, right? It's meant to be
available everywhere. The value of `command-line` (which can be a
parameter object) determines whether or not it is _useful_ in a
particular environment. Chez Scheme uses a command line of '("") in the
REPL, which I think is the best compromise (R6RS and arguably R7RS
disallow using #f or an empty list for the command line, so a
zero-length string is the next best thing).

The procedures in SRFI 193 are meant to be callable from anywhere. They
simply return #f in situations where useful information is not
available. (Well, command-line returns ("") for compatibility with RNRS,
and command-args returns '() to follow suit). The distinctions between
the various situations are very confusing to casual users. Indeed, I'd
prefer to have the luxury to forget about them myself :) The aim was to
design an API where the intuitive thing to do is also the right thing
from a portability/reliability perspective and have the various
situations and APIs be as symmetrical as possible.

> Consequently to all this, I suggest eliminating the script layer altogether.

If there is no script layer, how would you do (string-append
(script-directory) "input.csv") in a simple Scheme script?
`os-executable-file` doesn't work for that. (car (command-line)) kind of
does, but is more obscure and more difficult to use, and encourages a
bad habit: it's not wise to interpret (car (command-line)) as a valid
filename, since that works only intermittently. Relying on the current
directory to be the script directory is brittle as well.

"Layer" is not an entirely logical term since the three layers do not
form a stack, but I didn't think of anything better.