Oh damn it. I just wrote a longpost and my browser refreshed by accident, so I lost it. I'll just summarize it:
Even if you were a good marketing god, do you think you'd get people to swallow prefix and parens that easily? That seems to be what's putting most people off. I find it most natural, but some people don't.
On the other hand you have really complex and verbose languages like sepples that are still popular. Or simpler, but very verbose, sometimes limited languages like Java or C# which were marketed as a better sepples.
Both of those are a result of trying to make a better C. And then you have a lot of languages with C-like syntax and varying semantics, with varying degrees of popularity. Lisp syntax is very important as it gives you homoiconicity which makes true macros possible, among other things.
As for hiring a single programmer: I fear it may lead to guido-syndrome. The programmer will just include what they like and leave out features they don't. This is why you shouldn't hire Paul Graham or Rich Hickey, or any other single programmer. I'd hire a committee, just like Common Lisp was the collected knowledge of many current (at that time) Lisp implementations and ended up getting most of the good features picked up, while this also lead to some redundant things getting in there solely for compatibility reasons (make it easier to port old code).
I'd imagine this new CL would be a cleaned up CL(some redundant things removed), standardized MOP, maybe standardized FFI and networking/sockets (we have defacto standards for all of them! this is reason enough), clarified certain issues that never got fixed during the standardization, Gray(or simple) streams, maybe, I dare say, some standardized GUI(is this a good idea? There is CLIM, but even if it's rather nice, people don't seem to keen on it, it's also terribly complex), maybe make certain things in the package system more extensible than they already are(hierarchical packages, or something new altoghether, but not TOO different. possibly attempt to make major language redefition even more portable than it already is, without having to incur some speed penalties(inlined functions, etc, this is a complex issue, I doubt it would ever get fully solved)), even better/easier control of reader macros (lexical reader macros made easy?), locatives as part of the standard(as opposed to a tiny library), certain common utilities standardized (with-gensyms, once-only, etc), maybe dynamicly scoped functions (like aspect orientation), even more extensible numeric generic ops, standardized threading, specify portable pathnames better (implementations differ too much), maybe make some standard system definition facility (asdf is defacto and almost portable, however this might be a bad idea to standardize on), extensible/generic sequences, advice/function encapsulation, more specified/extensible type system, maybe better support for static typing (optional inference like SBCL does, but with more ways for the user to control it) and some other neat things I'm too lazy to think of now. Almost all of these features are supported in some (others in all) of the current CL implementations (which are actively maintained, but I'll just assume they're not as you said OP). Some are de-facto standards, but these things are still a bit messy and the user should know what to do to get everything working (It's not really that hard, but it doesn't beat a standardized alternative). While we can get all this today, it'd be cool to have all this supported by most/all implementations like CL is.
So, I'd imagine I'd have a committee of people working on it, probably selected via a community process(with open participation):
Some of the older guys who worked on CL(X3J13) or were involved in some direct way: Kent M. Pitman, possibly Steele, maybe Gregor Kiczales, Daniel Weinreb, Richard P. Gabriel and others (Erik Naggum if he was still alive ;_; included here since he apparently joined X3J13 later on, but I don't think he had any involvement in the released standard)Some implementors: Christopher Rhodes (SBCL), R. Matthew Emerson (CCL), lead LispWork and Allegro developers (Duane Rettig, Weinreb, others), maybe some of the ITA hackers.
Some library writers, reasonable users, researchers/"teachers": Pascal Constaza(CLOS-related research, AOP), Edi Weitz, Peter Seibel, Tim Bradshaw, Xach, maybe even Kenny(due to Cells), and many others (participating via the community process), authors of various de-facto standards (see up there), guys involved in CDR (
http://cdr.eurolisp.org/).
It'd probably end up lengthy and costly, but might yield something interesting, although with such a selection of people, you can't really hope to go too far from Common Lisp, but I'd expect many things to get ironed out and defacto standards to get edited, fixed if needed and passed into standards. One could go further and go specifying standard libraries (usually can be implemented using only portable means, think for example of CL-PPCRE) - it could include things like better unicode support, ppcre, xml parsing/output, and many more(all of which are currently available as portable or de facto portable libraries). It might end up like Java's large library.
All things aside, current CL implementations do allow either all or most (some allow all) of the things mentioned, and nothing would probably bear too high of a cost to implementors, if it was ever passed into standard (although there is this one feature I'd really like to have: thread-safe letf - they used to have those on Lisp Machines. I have no idea if this can be done without major overhead while still staying threadsafe, I believe P. Constaza implemented this portably with some clever hacks and progv, but that's likely less efficient than what it would be if an implementation offered native support).
It's still doubtful a marketing god would make people like Lisp. An interesting attempt of this kind was Dylan where they tried to take CL and ideas it had and removed the parens to try to make normal people like it more. It never got popular mostly due to marketing failures, not due to issues inherent in the language. However, to me a Lisp isn't Lisp if it doesn't stay homoiconic.