There's a reason there will never be a universal language.
Personally I'm happy equality doesn't work like common lisp. See here for a post explaining equality in CL: http://eli.thegreenplace.net/2004/08/08/equality-in-lisp
It's old and I don't use common lisp, so please correct me or the post if needed.
I've tried to get into lisp numerous times. Clojure was the one that clicked for me. I can't say if that's because of clojure or because it was just the right time for me after N times trying to get lisp.
Every now and then I poke at a scheme or CL. Scheme seems do-able for me, particularly Chicken Scheme, but I everytime I try CL, I come across what seems like too many functions to do what it seems like one function should do. Whenever I see something like SETQ, etc., that's a big turn off for me.
On the other hand, I really dislike Clojure startup times. Doesn't matter for server/long running apps, but when you are debugging or iterating, it gets to be a pain. There are some mitigations with their own set of issues.
Pixie and Hy have been brought to my attention. Pixie seems more or less abandoned, but Hy looks interesting. I haven't been able to tell from the docs if it has clojure datastructures (which are the best part of clojure), but Pixie does. So maybe sometime I'll try to bring those over to Hy and see if they get accepted.
Also, all programming languages implicitly have most of those equality operators. But yeah, Scheme's equality is a bit cleaner.
Not a super fan of Clojure datastructures. If I want to modify my cdr, than let my modify my cdr.
Note that linked-lists are only a good data structure in fairly narrow contexts (e.g. shared structure, certain types of mutation you can do). Since Clojure is focused on limiting mutation, it makes sense for them to use Seqs instead of linked-lists.
Racket's conses are merely immutable.
There is zero need to ever use SETQ for example. SETF is a pure superset of SETQ's functionality. For other examples, I don't know that I've seen a serious use of PROGV or PROG in this century either.
Most experienced lisp programmers never use EQ, since EQL is more well designed, and the overhead is either negligible or nonexistent. Yes it's annoying that EQUAL doesn't recurse into non-string vectors.
Useful equality in CL is roughly: EQL for comparing non-aggregate types and identity checking of aggregate types, EQUAL for comparing lists, and EQUALP for case-insensitive comparisons. Some people add in = for numeric comparisons, but that's a style question (seeing = means "these arguments are definitely going to be numbers" and not much else, as if you're doing an equality test between e.g. an integer and a float, then you're doing it wrong, and differing numeric types is the only time = is different from eql when all arguments are numbers).
Comparing non-primitives is typically done with domain-specific comparison functions, as there are many ways to decide if two arbitrary objects are "equal" (for the old-saw OO example of 2d geometric shapes, you might have shape-area-equal, shape-perimeter-equal ...).
Some things I like about CL:
I find its package and macro system combine to be an amazing sweet spot of simplicity and power for metaprogramming. Scheme's hygienic macro system is the stuff that earned several people their doctorates; CL's is explainable in under a minute, and 99% of hygiene problems are solved by the package system (IIRC Clojure inherits its macro system from CL, using namespaces to solve the "FLET" problem).
CLOS+MOP made me feel like perhaps OO wasn't the colossal mistake I'd always thought it was. It's not the only great OO system out there, but it is great and so much better than the various C++ derived systems that I was first exposed to that it will always have a special place in my heart.
The condition system is great. The only quick summary I can give is that you can have condition handlers run in the stack context in which the exception was thrown (which lets you do much more useful things than running in the context in which you establish the handler, which is how all other exception systems I've seen work).
Common Lisp has amazing development tools; in particular the combination of SBCL/SLIME puts nearly all other F/LOSS IDEs to shame[1]:
It's a high-level language, but you can view a function's disassembly, capture instruction-level profiling data, recompile a single function and rerun all of that without stopping your program. The overhead of edit/compile/debug is essentially zero.
All that being said, I do need to take a look at clojure again (I went through Fogus's "Joy of Clojure" book when it was new, but haven't touched the language since).
1: http://pryrepl.org/ is apparently an attempt to bring some of this to Ruby, but I have on many occasions seen Ruby programmers say that "If you're using a debugger you're doing it wrong" and Pry doesn't seem to have a lot of users.
Personally, I greatly prefer ML style languages to lisp style languages. I get fed up with all the parentheses in lisps.
http://bloomberg.github.io/bucklescript/
It's in the OCaml-to-JS family.
It's been tough for me as a new developer to learn this stuff without nearly as many resources as there are in the Python and Ruby communities for beginners, but there's no question this is the (near-term) future. Plus, a lot of that stuff just complects everything anyways and doesn't have to apply anymore (read: mutable state, no Value on Values).
Let's keep it Lispy. ;)