Why wait?

  user=> (defmacro mapp [part coll & colls]
          `(map (partial ~@part) ~coll ~@colls))
  #'user/mapp
  user=> (mapp (* 2) [1 2 3])
  (2 4 6)

On one hand I feel the same - Shen looks incredibly nice. And it features a lot of things that I hope Clojure will have in the future (such as an optional static type-systems and high portability due to Clojure in Clojure). Then on the other hand a language's usefulness is to a large degree determined by having a minimal viable userbase - you just cannot write every library yourself. And by being highly pragmatic, running on the JVM and so forth (and probably many other things I don't comprehend) Clojure has achieved just this. So I think right now its the most practical Lisp. If Shen has a lot of nice features maybe we can learn from it!

You don't need Shen features in Clojure because the Shen team aims to provide a compiler for KLambda which is a very small subset of Lisp. It should be no problem to implement KLambda in Clojure.

Quote from https://groups.google.com/group/qilang:

"Much of the work necessary for converting to Clojure or Python (Or any other non-tco language) is being done as a pass over KLambda right now in my JS port. Once this is finalized, it should be relatively easy to port the transformed KLambda code to any architecture that supports exceptions or labels."

Clojure provides function arity overloading and varargs, so automatic partial application is out. It's a tradeoff that Clojure alleviates by providing a lightweight function literal:

    (map #(* % 2) [1 2 3])

An added advantage of Clojure's approach is that it's not limited to partial application on the last argument.

To provide implicit partial application or arity overloading and varargs is a fundamental shift in the way that the language operates. However, the gap between (in the direction Clojure->Shen only) one and the other is 2 characters, or a mapp macro like Alex showed. I'd make that trade any day of the week.