> Is there a particular reason why SRFI-23 specifies "error"
> to have a single argument?

Actually, there is.

> I'm just asking, because many
> Scheme implementations accept zero or more optional
> arguments (in addition to the message), which are output in
> addition to the error message.

That is true. However, in some Scheme implementations (e.g. Bigloo),
the arguments have a very specific meaning.

My reasoning was that `error' is a pretty good name, so almost
any implementation will want to use this for its own idea
of what error handling is, and this SRFI should conflict with
that as little as possible. So therefore the arguments of
error are very restricted: not only is only one argument allowed
but it has to be a string. The idea is that this allows the SRFI-23
error mechanism to co-exist with some implementation-specific
error procedure.

An example of this is given in the SRFI for Bigloo.
Note that the zero-or-more behaviour can be done on top of this
SRFI by doing:

(define (my-error . args)
   (error (apply string-append args)))

This doesn't work when args contains arbitrary objects, not strings.
I am open for discussion on how problematic this is.
Perhaps another name should be chosen that isn't so likely
to conflict with already-existing features.

> How exactly the stuff is presented
> to the user can still be implementation dependent.

Of course, but at least the semantics should be (somewhat) fixed.
It is not good if one implementation decides the 2nd argument if
the line number if another thinks the 3rd one is the line number.

Stephan