In some environments any requirement for an executable as single file may be awkward.
In a Unix-like environment an option could be to concatenate a shell script stub followed
by the contents of some kind of archive. However, to execute the program, the script might
have to uncompress the script in a temporary location, which is possible, but could be expensive.

If this SRFI allowed that the executable consisted of multiple files, it would be quite hard to use the command ‘compile-r7rs’ described by this SRFI in a portable way in, say, scripts and Makefiles (and would go against the idea of a POSIXy executable).

As long we have the guarantee that only one file is produced, an installer will know what to do (e.g. copy the file to /usr/local/bin). If not, I don't know.

While the sample implementation provided with SRFI 138 doesn't do more than appending literal Scheme code to a shell stub, I expect that many implementations who want to support SRFI 138 want to do more sophisticated things. E.g., they could produce an ELF binary that holds the Scheme code (in a suitable format) in a data section.

FWIW: I was surprised to find out you can concatenate a shell script with the .jar
(Java Archive) file, and have the shell script call something like 'exec java -jar $0'.
I.e. the java command can skip the shell-script preamble when looking for the jar contents.
So that may be a possible approach for Java and other JVM-based implementations.

This is good to know, so Kawa should be able to implement this SRFI! Is this the official way how JVM-based programs are turned into proper executable files?

Marc