Thanks for the feedback!

> `scheme-script' is part of R6RS and is assumed to point to an
> implementation of R6RS. I wouldn't reuse the name for interpreters of
> other Scheme dialects as this can cause confusion or can clash with
> existing R6RS implementations in the search path.

scheme-script in the non-normative appendix, not in the normative standard.

An implementation of R6RS (without further qualification) is also not
useful for writing practical code with environmental dependencies.

I would consider the ability to declare dependencies (listing the
required libraries/modules/eggs; acceptable version ranges for each;
supported RnRS editions; and supported Scheme implementations) inside
the script file itself to be a requirement for a useful scheme-script.
How to do that in detail should be worked out; a collection of real
scripts is a good litmus that the spec is useful.

> Of course, R6RS and R7RS are similar enough so that one can write a
> script using their common syntax and semantics as long as the
> `scheme-script' implementation has access to enough libraries (including
> the base libraries `(rnrs base (6))' and `(scheme base)').

This would be a point in favor of a combined R6RS+R7RS compatible
standard. But I've trolled enough about that for the time being :)

> SRFI 22 suggests `scheme-XXX' where XXX corresponds to the version of
> Scheme.

IMHO that's going back in the direction the bad old days of general
incompatibility :) We've standardized Scheme's library system, where
before we used to have incompatible module systems in each
implementation. We can standardize a cross-RnRS-compatible and
cross-implementation-compatible scheme-script as well.