Well, if first and rest are unsuitable for parallelism as Steele says, a programming edifice built on top of better implementations of those might be beside the point.

My understanding of the slides is that we don't need better language runtimes to exploit parallelism for us while we continue to write the same kind of code as before; what we need is a new set of primitives (modeled by conc lists in this talk) that would allow us to compose programs differently, with more parallelism. And that far from being insulated from this, programmers will have to be thinking about it throughout.

It's possible that Clojure's implementation is already such that these primitives, and a programming style built on them, are feasible today. If so, that's awesome. But this is a different thing than providing better implementations of cons-based abstractions.

Edit: another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one?