> archaic elements due to design by committee

The 'archaic' elements are due to backwarts compatibility with Lisp. You get that raw core of Lisp from the 60s: s-expressions, cons cells, LAMBDA, LIST, CONS, CAR, CDR, APPEND, COND, EVAL, PRINT, PROG, READ, macros, dynamic binding, ... all these (and more) are still in Common Lisp.

Common Lisp is an improved Lisp dialect, not a fully new language. A goal was to relatively easily port some existing software which was written in the years from 1958-1984 to Common Lisp. CL appeared in a documented form in 1984 with CLtL. Thus some code that ran in Common Lisp was a port of code written starting in the 60s, like Macsyma. People did not want to throw away hundred thousands lines of code and they wanted to use the newer language, because it was available, slightly better than the old one and was supported on more machine types.

This language was mostly developed by five people: Scott Fahlman, Guy Steele, David Moon, Daniel Weinreb, and Richard P. Gabriel.

> and trying to put something together to unite the many different lisp implementations at the time

Common Lisp is specifically a successor to Maclisp, mostly based on Lisp Machine Lisp (another Maclisp successor), by simplifying/generalizing LML. It's even not directly compatible with LML. It's much less compatible with other Lisp dialects of the time: Interlisp, Scheme, IBM's Lisp, Standard Lisp, or even Scheme or Logo.

After the initial design of Common Lisp was done, an effort was started to standardize the language: improve it and add a bunch of important features like error handling and object-oriented programming.

Error handling was then based on the Symbolics 'New Error System' and the object-system CLOS was a new design based on Flavors and LOOPs - two earlier Lisp extensions.

The most committee like design was actually CLOS. But even that was driven by only six people, lots of community support and a portable reference implementation (PCL).

Arguably, CLOS is one of the greater designs in the Lisp language space.

The third part then are implementation extensions, which got especially important, when the standards effort went out of steam/funding/interest...: concurrency, unicode support, foreign-function interfaces, standard libs, ...

The design advantage Common Lisp has over Scheme is that it started as a larger integrated language. This makes features know of each other and the language is designed to use and support them.

Scheme has often this feeling of a very small core language, even a too small core language, and a lot of stuff bolted on top. The result is that 'practical' implementations (practical here means implementations which are used to write software and not so much as a teaching language/implementations) often reach the size of Common Lisp and one of its implementations AND all of them are diverging in some basic ways (Chez, Chicken, Racket, Guile, ...).

Take for example the object system. Since CLOS was added to Common Lisp no one bothered to propose a replacement for it in Common Lisp. Thus every implementation, small and large, is using it.

> but the Chez Scheme migration should help out Racket a bit

If I would want to use Scheme, I'd use Chez Scheme directly. It's a great implementation of Scheme. In provides what many Common Lisp systems (incl. SBCL) also offer: an optimizing native code AOT compiler. Chez already has what Racket now gets: an improved implementation mostly written in itself.