I think it has to be in the syntax so that implementations can diagnose
it as an error.
Remember that &whatever are ordinary symbols.
If the documentation only said this:
"A destructuring lambda list can contain all of the lambda list
keywords listed for macro lambda lists except for &environment"
and made no other mention of the parameter, then a possible
interpretation would be that: destructuring lambda lists do not support
&environment --- and therefore, in destructuring lambda lists,
&environment is just an ordinary symbol which is semantically a
parameter name.
According to this interpretation, implementations would not be able to
reject it, only emit a nuisance diagnostic like "warning: &environment
is an ordinary symbol in destructuring-bind", but then obligingly
proceed with the symbol as ordinary, in order to remain conforming.
The syntax makes it clear that destructuring lambda lists *have* an
envvar phrase structure in the *syntax*. The other requirement makes it
clear that *instances* of this phrase structure are not supported
for that kind of lambda list.
Just because something is in the syntax doesn't mean it may be used;
languages often allow more combinations in the syntax than is
semantically valid.
E.g. in C, "unsigned short double" is valid syntax; a constraint rule
rejects this combination of specifiers as invalid. Static type checks
are another source of examples of the concept.
--
TXR Programming Language:
http://nongnu.org/txr
Cygnal: Cygwin Native Application Library:
http://kylheku.com/cygnal