> It appears at least in the formal semantics in section 7.2 of the R7RS,
> see "wrong".

Ah, that is the denotational semantics part :) You are right, but I'm
not competent to interpret them.

> For this, SRFI 64's `test-error' and `test-read-eval-string' would
> already be enough.

It doesn't distinguish arity errors from other kinds of errors. An
`arity-error?` predicate could be plugged into `test-error` (if its
`error-type` argument is extended to allow predicate procedures, which
seems reasonable and permitted by the SRFI 64 definition).

> As far as I have understood, one of the main complaints about R6RS was
> that it forbids extensions to standard procedures (for example, in the
> form of extra arguments).  In R7RS, it is no error if the domain of a
> standard procedure is silently enlarged by an implementation.

This is all well and good.

> Thus, any test case that would complain about a procedure accepting
> spurious arguments would in some sense not be a portable test case
> (unless a specific specification would forbid as in the R6RS the
> extension of the domain of a procedure) and not very helpful outside of
> a particular implementation.

Most Schemes ship with SRFI implementations/tests tailored specifically
to that Scheme. Then the implementor can freely pick and choose which
test cases make sense for that implementation, and leave out the rest.

For portable SRFI test suites, the arity tests can form an optional
sub-suite. It's not particularly troublesome to split a test suite into
multiple parts and keep only some parts for each Scheme implementation.

Accepting only the arities specified in the RnRS/SRFI is probably by far
the most common case in practice, and accepting extra arguments is a
fairly rare exception.