I developed a language called TXR Lisp, which has ties with Common Lisp in many areas. If you look at the reference manual, which is conveniently one giant manual page available in HTML form, there are numerous dialect notes that mention ANSI Common Lisp; a chunk of that would likely be things I might change in Common Lisp.
Some things I would fix without changing Common Lisp:
* redefine "binding" as being an association between a symbol and a location.
* I'd make (setq x y) have a predictable, documented effect when x is not a defined variable. It would cause x to be bound to its value cell, and place the value of y into that cell, and that would be the same as (setf (symbol-value 'x) y).
* pick up some outstanding issues and resolve them, like this one: during a dynamic control transfer, an exit point is identified for that control transfer and then unwinding takes place. It is not specified in CL whether the intermediate exit points (the ones not selected for the transfer which are being skipped) are torn down before the control transfer takes place, or torn down as-you-go during unwinding. I'd fix that as being tear-down-as-you-go. This affects situations when an unwind-protect intercepts a control transfer and then tries to initiate a new one to a different exit point.
* I'd fix the order of evaluation of a function binding relative to the arguments. We know that in (f x y z), the x y z are evaluated in left to right order, if f is a function. However, we don't know whether the f binding is resolved before or after the arguments. I'd pick one order and require it; probably before the arguments, though that requires the longest possible temporary storage. Obviously there are situations in which the binding isn't evaluated each time the function is called, like when it has been inlined.
* loop would support application-defined clauses.
* structs and CLOS would be integrated together; conditions would be CLOS instances.
* in the area of pathnames, I would have the language specify precisely how POSIX and Windows paths correspond to pathname objects. Every implementation would have to follow that. For instance, it couldn't be that one implementation sees "foo.c" has having a type "c", and another one doesn't. Everything would be specified down to what happens with double slashes, and trailing slashes.
* string literals would support escape sequences for special characters. Also, Unicode would be required. Implementations would have to support UTF-8 code.
* string literals would support a way of splitting across multiple lines, such that the reader eats the leading indentation. Thus, the format function wouldn't need a hack for this.
* FFI would be in the language.