> It's not broken because you can use it distribute executable R6RS
> programs, which are portable by design. You also have to distribute
> accompanying libraries, of course, but this is no different to typical C
> programs.

That's using an academic and largely impractical definition of the term
"portable". The first problem is that R6RS doesn't specify how the
implementation finds libraries in the file system. And the problems grow
from there.

Are we really pretending that there are a large number of substantial
R6RS programs that don't depend on a particular Scheme implementation,
and don't depend on particular libraries, FFI, packages, etc.? It just
doesn't seem like we would be causing practical problems to many people.

Anyone who wants to ship a Chez Scheme program using chez-srfi and some
FFI stuff, should just call `chezscheme --program` instead of
`scheme-script`, and it doesn't seem sensible to compile that a
`scheme-script` breaks a program like that.

> Because of the same reason that you would rather call "cc" or "c99"
> instead of "gcc".

If we can work out a scheme-script that does something reasonable when
there are no declarations present in the file, that's a good thing.

"cc" (with no knowledge of which compiler it is) lets you compile
something akin to ISO C90 ("ANSI C"), using only the standard library,
with high confidence that your program works. The Scheme equivalent
would be if scheme-script is guaranteed to be roughly R5RS compatible.

To get C99 or GNU C, you have to call "gcc -std=c99" or "gcc
-std=gnu99", things like that. You can no longer rely on "cc".

> Why is everyone in the Scheme community so eager to repeat the same
> mistakes that have led to so many splits in the community? R6RS
> introduces gratitious incompatibilities to prior SRFIs; R7RS introduced
> gratitious incompatibilities to R6RS.

R6RS is normative, and is far more central, widely used, and
irreplaceable than scheme-script. R6RS was also reasonably specified to
begin with, whereas the whole idea of a scheme-script tied to an RnRS is
dodgy, irrespective of the details of the spec. There are facilities in
POSIX that are standard (normative, even), but widely considered broken
as designed (e.g. file locking, definition of leap years). It doesn't
pay to adhere strictly to a standard in every detail (especially given
that scheme-script is not normative).

> That argument would only be correct if `scheme-script' were the only
> possible name that isn't misleading.

The point is not to look at one name in isolation, but the collection of
all our command names taken together. That collection is confusing, and
will become more confusing if we add new names. That's what bothers me.