> I think you are missing the point. There is no universal s-expression
> format. A priori, you just have text, which you have to interpret.
> Different Scheme implementations use different formats (e.g. for
> bytevector literals in R6RS and R7RS; other Schemes may have more
> complex reader macros, etc.).

Of course. The key is to decide what level of compatibility to go for,
and then write the code in the common subset of those standards /
implementations. Increasing portability usually adds some pain.
cond-expand adds pain, and a lexical-syntax-cond-expand would add even
more pain. If the latter is desired, it would be better to standardize
in the language than in a bundle file format, but I think it's
overengineering.

> There is a distinction to be made between the representation and the
> actual structure.
>
> The crucial principle is that a program should never try to parse
> another program's representation for data. This principle is much more
> important than any aesthetic considerations. It forbids that a script
> consists *solely* of s-expressions.

I find the aesthetic consideration much more important. Aesthetic
mistakes cannot be rectified later; it puts the "ecosystem" on a
downward spiral of getting more and more messy over the years.

In the case of embedding (declare-file ...) in Scheme or Lisp syntax, we
don't parse another program's representation; instead, the script writer
promises to use a syntax (in the relevant part of the file) that is
compatible with both the target Lisp standards/implementations, as well
as the (declare-file ...) spec which specifies its own lenient version
of S-expressions. Note that you need to do the same with magic comments
and the like.

You could specify that the launcher always rewrites the file, removing
the (declare-file ...), but that adds the complexity of temp files,
messes up line numbers in stack traces, etc. Nothing is gained.