Clojure seems to have most of what he wants- I wonder if he's aware of it.
It's nice to experiment with stuff like persistent data structures and STM, but I don't think the next big Lisp, if there is one, will be based around that model.
It's simply too far removed from the (object-oriented, semi-functional) Lisp programming model of the last decades.
~ahem~ Common Lisp and Lisp are not equal. Well, maybe in a sense, but they're definitely not eql.
Anyway, I'm still unsure about Clojure myself (not really had the chance to dive in), but a lot of the 'unproven' ideas you mention (persistent data, STM, also lazy functions etc. etc.) have been doing the rounds in PL circles for quite a while now. It's interesting to see them taking root in lispsville, if nothing else.
I like Lisp and I like Haskell - Clojure seems to take cues (very well proven ones, I might add) from both but, like I say, I've yet to really see how well they've been married.
My $.02
I disagree with your claim, both here and in the OP, that the Lisp programming model is object-oriented. CLOS is just a library, one can write arbitrarily complex Lisp programs without going near it, and many Lisp hackers don't. Thinking in Lisp is not at all the same thing as thinking in objects. (After building OO systems for years, one reason I like Common Lisp is that I want nothing more to do with OO.)
The reason CL is semi-functional is not CLOS but the fact that it fully supports imperative programming, leaving it up to the programmer to decide what side effects to allow where.
And it grows, including towards what you it's say it's lacking right now. Recently it got the capability to work with mutable data structures (transients), which makes it less functional, but still without giving up the advantages.