My personal take: CL is a multi-paradigm rummage bin that demonstrated to the world the greatness of many features (e.g. macros, CLOS), but is also beset by many design flaws--some due to genuine infelicity of conception, and some due to unavoidable limitations of software and hardware at the time. (For one thing, there are approximately 101 ways to test equality). The result is that you could be a career CL programmer and see code written in a style you've never seen before, and that it suffers from design flaws that, if fixed, would result in something that would no longer be Common Lisp. Scheme's problem is kind of the opposite: it's stripped down, but also has not purged all of CL's unfortunate baggage, and very conspicuously lacks an out-of-the-box and full-featured package manager.
Clojure, being just over 10 years old, has gotten to benefit from decades of witnessing other languages' spectacular design disasters, and it was designed by one person in a few years instead of by committee over decades. This results in a language that is much more aesthetically coherent, adhering to a pragmatic flavor of FP, and avoids a lot of gnarly warts: for instance, Clojure has one basic way to test equality irrespective of data type, and all basic data structures are immutable.
I'm not sure you've picked the right example here - far from being a gnarly wart, differences types of equality are a fundamental issue. Your language can choose to either a) hide it effectively (constraining some things) b) expose it to the user which means they have to think about it or c) try (a) but leak and give weird corner cases.
It's not obvious that (a) is superior to (b), an (c) is often what you get.
In the abstract you're right that equality is subtle and complicated, but it seems to me that in practice, most practicing software engineers just want value-equality on garden-variety data structures most of the time (remember == for Strings in Java?), and that for this use-case, a leaky abstraction is fine--preferable, even. At least, the alternative--forcing users to consider the subtleties of equality even in circumstances where it can be safely ignored and having them memorize dozens of cryptic equality operator names--is excessive and unnecessary.
I'm not really saying any of those choices is wrong (although clearly you can make design mistakes that make the leaks problematic, if you pick (c)). It's more that none of them are clearly right.
Really I'm rejecting the idea that that equality as presented in CL was any of: wrong, design by committee, or something we have learned do better since '84.
There are historical artifacts in CL that aren't great (cf filesystem stuff) but this wasn't a good example in my opinion.
I hear your argument - not fully convinced other than in a 80/20 sense. And CL was not designed as a language to leave the 20% out in the cold.
To be fair I don't find clojure compelling as a lisp but I don't think I'm being biased in above.
I've had a lot of success in my own language designs with dividing the problem into two cases, equality and identity, or EQUALP and EQ in CL lingo. Despite having written a ton of CL over the years, I still fail to remember the specifics of EQL & EQUAL. Defaulting to full value equality does come with a performance cost, but I feel like we're mostly past the point where we should waste precious time on these kinds of micro optimizations for most use cases.
I agree at least separating identity and equality seem to be important in practice. I'm not completely sold on where the other lines should be.
I don't love the CL implementation, particular eql vs equalp on numerics seems fiddly, and it's hard to keep all the cases separate. Homoiconicity introduces the need for a "representation equality" i guess which isn't always needed, etc.
Clojure, being just over 10 years old, has gotten to benefit from decades of witnessing other languages' spectacular design disasters, and it was designed by one person in a few years instead of by committee over decades. This results in a language that is much more aesthetically coherent, adhering to a pragmatic flavor of FP, and avoids a lot of gnarly warts: for instance, Clojure has one basic way to test equality irrespective of data type, and all basic data structures are immutable.