> That is an orthogonal problem. To solve this, you have package managers
> like Akku; one could even reuse a distribution's package manager like
> Debian's. The situation is not much different to Python here.

Package managers can (and do) also rewrite #! lines in scripts to match
the target environment. configure scripts can do that as well.

>     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.
>
> What you seem to suggest here is that portability of R6RS is virtual.
> The editors of this dialect obviously thought differently.

My claim is that the set of generally useful programs requiring only
R6RS with no third-party libraries, implementation-specific extensions,
FFI, etc. is small. More strongly, I claim that there are no programs
popular enough to be shipped to the public via Apt, Yum, or Guix, such
that those programs need scheme-script to work in the R6RS way.

It's likely that most substantial R6RS programs require a particular
Scheme implementation (instead of just R6RS in general), and should
directly invoke that implementation. The rest can rewrite the #! line
using a package manager or autoconf anyway, or else use something like
the proposed new, more flexible scheme-script.

The idea of a generic script interpreter that doesn't address
environmental dependencies beyond a language standard is obviously
inadequate to begin with. That's why they put it in the appendix.

> "c99" is standardized by POSIX.

Ah, that's probably good.

> And if you need more, you still don't
> write "gcc" but use, say, $(CC) and/or some mechanism like Autoconf.

Yes.

> It's not about whether you or me should adhere strictly to it or not.
> The problem is that using `scheme-script' for anything else rules out
> peaceful coexistence with implementations that want (for whatever
> reasons) to adhere strictly to the full R6RS document.

By all means, we should strive to make things as compatible as possible.
Something that transparently supports both the appendix and declarations
is ideal, for sure.

> You can't seriously mean that there would be less confusion if the same
> name is used for two different things.

It depends. I'm under the impression that the R6RS-appendix-correct
behavior of scheme-script is not very widely known.