Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

Alternate proposal that has a declarative syntax, and is probably a lot
more comprehensible.

  [ &DECLARATIONS declares-var [ &DOC-STRING doc-string-var ]] &BODY body-var

If somebody wants to call it &DOCUMENTATION-STRING, go ahead; CLtL
usuually abbreviates "documentation-string" it to "doc-string".

Full semantics:
 - Since &BODY can only be used in macros, these extensions may
   only be used in macros.
 - &DECLARATIONS may only appear if &BODY appears.
 - &DOC-STRING may only appear if &DECLARATIONS appears.
 - If any of these extensions appear, they appear in the order given, on
   the grounds that is the normal order found within code.  It probably
   makes parsing defmacro's lambda-list a bit easier, and uniformity
   will make code easier to understand by other than the author.
 - declares-var is a catenation of the declarations.  If the original
   body had
	(declare (ignore a))
	(declare (ignore b) (inline aref))
   then declares-var would get bound to
	((ignore a) (ignore b) (inline aref))
 - If &DOC-STRING is present, the first string of the unpruned body is
   the documentation string, and parsing/pruning stops with the second
   string, which is considered part of the implicit progn.  [The
   exception is a string that is the last form of the body, in that case
   it is part of the implicit and not a doc-string, just like now.]
 - If &DOC-STRING is not present, then the first string stops the
   parsing/pruning of body.  Any declares after a string are part of the
   implicit progn and "are an error".  Presumably the code that groks
   implicit progns will complain about the presence of declares.
 - body-var is the body without the declarations and/or doc-string, and
   also with the first form NOT macroexpanded, even though
   macroexpansion was necessary to search for declarations and
   doc-strings.  If the first form is a macro, it may get expanded
   again.  Tough, macros shouldn't have side effects.

I believe this nests correctly, as all the other defmacro destructuring
does.  [Example deleted because even the simplest one is 16 lines long.]

I am willing to endorse this; I more-or-less believe it.  I do not
believe the original
	&BODY body-var [something-var [something-else-var]]
because it is totally lacking in syntax and comprehensibility.

Aside #1: I personally think &KEY and &BODY are mutually exclusive
because of their semantics; more-so when we worry about the presence of
declarations and a doc-string.  This is because the semantics of a body
includes an implicit progn, whereas the semantics of keyword/values is of
markers and values.  For those that do want &KEY and &BODY at the same
time it is probably necessary to require that the &KEY parsing happens
after the declarations/doc-string pruning.

Aside #2: If we had a simply specified PARSE-BODY, the simple
implementation of the above would be
	(multiple-value-bind (declares-var doc-string-var body-var)
	    (parse-body original-body want-doc-string environment)
	  ...)
I think we should have a (simply specified) PARSE-BODY even if (some)
extension to &BODY is adopted.  The compiler and special-form groker
need them for the same reason users want them for defmacro.  I think
PARSE-BODY and an &BODY extension should look very similar to each
other.  I believe the ideas in this messages show such a similarity.