You need to hack around it. Don't like it? Improve it. Sketch:
(defun make-vars (vars &aux syms)
"creates uninterned symbols for vars named NIL.
Returns a list with those replaced and a list of the new syms."
(values (loop for var in vars
if (eq var NIL)
collect (let ((sym (gensym "ignore"))) (push sym syms) sym)
else collect var)
(defmacro multiple-value-bind-some (vars form &body body)
"Similar to MULTIPLE-VALUE-BIND, but variables named NIL will be ignored."
(multiple-value-bind (vars syms) (make-vars vars)
`(multiple-value-bind ,vars ,form
(declare (ignore ,@syms))
(defun foo (x)
"returns five values"
(values x (* x 2) (* x 3) (* x 4) (* x 5)))
(defun test ()
(multiple-value-bind-some (a nil nil nil b)
(list a b)))
Of course it now also leads to one of Lisp's other problems; namely that after a while everyone ends up programming in their own private language of accumulated hacks :D
1) Learn to deal with a language which has an infinite number of syntactic abstractions.
2) Learn the typical patterns of syntactic abstractions (WITH- , BIND-, DEF- ...).
3) Learn how to write your own abstractions.
Then groups will settle on common (!) Lisp patterns. See for example:
There are lots of libraries which provide language extensions, which are used by many people.
The extremes in Lisp are then:
* no syntactic abstractions -> the power of Lisp wasted
* using those syntactic abstractions which are approved by user groups, due to inclusion into libraries
Above choices are relatively conservative.
As another extreme, it is fully possible to change the language - but then Common Lisp provides more than macros to do so. See for example reader macros, CLOS MOP, customs evaluators/compilers, code walkers, ...
Now I'm trying to make a concerted effort to follow the recommendations here:
Hopefully this will lead to a modern set of consolidated libraries. Effectively a new Common Lisp standard: CL-20xx