Here are my comments:

The name "scm-i3e1178-90" is bizarre and I will not remember it.
Why not "scm-ieee-1178-1990"?  Also I don't like the prefix "scm-"...
why not the more explicit "scheme-" prefix?  I think the 32 character
limit for the script-interpreter line is a lame argument.  It is
hard to find a Unix that has this limit and in any case the line

#! /usr/bin/env scheme-srfi-0

(which I hope will be the most frequent case) is 3 characters short of
the 32 character limit (sorry to those fans of the IEEE standard
wanting to be portable to very old Unices!).  Note that you should use
the path "/usr/bin/env" which is more standard than "/bin/env" (for
example on MacOS X "/bin/env" does not exist).

In the document you say:

  Single-Line vs. Multi-Line Invocation

  Another common convention for implementing Unix scripts is simply
  to treat an initial line starting with #! specially and using the
  terminating newline as the delimiter. However, some Unix
  implementations limit the length of this line and/or the number
  of command-line parameters available on it. Therefore, a special
  terminating delimiter different from newline is necessary.

This comment only makes sense if you buy the 32 character limit
argument and there are (many) options to pass to the script
interpreter, or the path is long.  But in fact, by using the
"/usr/bin/env" trampoline, a path is not needed on the interpreter,
and there are no SRFI-22 specific options to pass to the interpreter.
The need for a multi-line invocation is just not there and it makes
processing of the script header more complex.  SRFI-22 could simply
say that a script must start with the single line

#! /usr/bin/env scheme-XXX

and that's it, the next line is Scheme code.  It is portable, it can
easily be parsed by a Scheme script compiler, and finally a UNIX
script can be converted to Windows by replacing "#! /usr/bin/env " by
"@;", which can be automated very simply.  I don't see the need for
several ways of writing a SRFI-22 compliant script (trampoline or not,
/usr/bin/env or /bin/sh or other trampoline, etc).  It is bound to
make the scripts less portable (I can easily imagine someone using a
"/bin/sh" script with an option that is not standard, or a trampoline
that is not standard, like "/bin/env").  By adopting a single well
defined syntax we avoid such portability problems.  Obviously,
individual users can write scripts as they please, but SRFI-22 should
take a strong position regarding portability.  SRFI-22 compliance
should be both a property of Scheme systems **and** Scheme scripts.

Finally, I don't understand the sudden change in the way parameters
are passed to "main".  It seems much more elegant to define "main" as
a procedure with as many arguments as are needed by the script, which
allows the Scheme interpreter to very naturally catch wrong number of
argument errors, and the code for scripts expecting a fixed number of
arguments is more elegant (they don't have to extract the arguments
from a list).  Scripts that handle variable number of arguments (such
as your example) can be written with a rest parameter:

(define (main . arguments)
  (for-each display-file arguments)
  0)

Marc