&NO

[Alan Bawden <ALAN at MIT-MC>]

This is my vote against the proposed lambda-list syntax.  I don't see
where it offers a substantial enough improvement in anything to make
it worth our while to re-write all the existing &mumble parsers.

I don't buy the argument that extending the syntactic space so as to
allow for everybody's flavor of destructuring is desireable.  This
moves me straight into the destructuring-doesn't-belong-in-lambda-lists
camp.  While before I was willing to select one flavor of destructuring
for lambda-lists, overloading lambda-lists with ALL kinds of
destructuring seems absurd to me.

I suppose the ultimate outcome of this is to allow the user to define
his own lambda-list keywords:

(def-lambda-list-keyword (one-or-more-of x) ...)

would be the way to extend lambda in the direction of LSB...