Hopefully a Clojure user will correct me, but something like (1 2 3) has a single printed representation for slightly different data structures. You can construct something which prints as (1 2 3) and when you read it, then it is something else.
It might not be a big deal, but from a language design view I would expect the single most important external data structure representation in Lisp - a list - is not overloaded with different data structures, where basic operators give different results. I personally would also think that in Lisp the predicate list? is fundamental and returns true for everything which looks printed like a list.
Common Lisp has a related problem for arrays: there are some attributes of arrays which have no printed representation. One will read an array back, but it might lack some features - like not having a fill-pointer. But atleast ARRAYP will still return true.
This seq/list thing might not be a big deal in practice, but it's another design wart. The language has in several places names, which are fundamental in Lisp and which mean something totally different now. Like 'atom'. Since the concept of a Lisp atom no longer applies - remember we have seqs, not linked conses - the name was reused to mean something different. atom used to mean (not (consp thing)) now it is something else.
isn't the printed representation of a list. It's just the printed representation of a sequence, which could be a list, a lazy seq, or others.
I'm not a Clojure expert, but when I use it, it looks like everything that responds to seq? prints in brackets. And so I tend to think of a seq as the fundamental, most important data structure in the language, and think of a list of just one kind of seq. And following from that, the seq? predicate is fundamental and returns true for everything that prints like a seq - which includes lists.
So maybe this seq primacy means it would be more accurate to call Clojure "Lisp like" or "a Lisp descendant" rather than "a Lisp"? I'm not sure.
I like Clojure, I like CL, and I tend to use and enjoy them both without worrying too much about taxonomy. Having said that, it's totally fair and important to ask the questions you asked!
For me, though, the answers to those questions don't make me like or dislike Clojure or CL more or less relative to each other. They're both fun and useful, and I'm glad they both exist. :)
Clojure isn't Lisp because it doesn't run Lisp programs and has different syntax and semantics to Lisp. McCarthy's original Lisp, Lisp 1.5, Maclisp, Emacs Lisp, Zetalisp, Common Lisp, EuLisp, etc, can share nontrivial programs written for each other with little to no modification; that's why people talk about them as versions of the same language. That doesn't hold at all for Clojure.
That isn't a complaint about Clojure at all, Clojure is a really cool language and does some things better than Lisp, but it's just not a Lisp, it's a Clojure. It borrows some syntax from Lisp in the same way that Java borrows some syntax from C, and it makes about as much sense to refer to Clojure as Lisp as it does to call Java C.
If you want to say that Clojure uses sexprs for source representation, say that; if you want to say that Clojure has dynamic typing and lexical closures (the latter of which most Lisps have not had), say that. Calling it "Lisp" to mean whatever handful of features that you personally think are the defining elements of Lisp doesn't aid clear discussion.
Of course the meaning of (not (consp thing)) for atom is classical, but don't you think it's a bit weird? It always struck me that way. In a language where lists were the only composite data structure (i.e. not being a cons means being a number or a string or a symbol), it made sense, but that meaning degrades once you have vectors and hashtables. Those are no more deserving of the name 'atom' than lists are. Indeed if one indulges in the oxymoron of treating atomicity as a spectrum, vectors feel more atomic to me than lists while hashtables feel less atomic.
Older Lisps didn't tend to have strings as a separate datatype, they just used symbols and there was a function EXPLODE (and similar) for turning a symbol into a list of one-character symbols (or fixnums), and a corresponding IMPLODE (and similar) for combining them again, and that's how string processing was done. Vectors and hashes predate "real" strings in Lisp as far as I'm aware.
The older Lisp (60 and before) talked about 'atomic symbols'. ATOM checked whether something is an 'atomic symbol'. Cons cells were not atomic symbols. They were pairs. But atomic symbols could be symbols, numbers, functions and variables. Arrays were not there in an explict form and the few data types of Lisp were made of atomic symbols. A number was an atomic symbol where the name starts with a digit and the symbol's assoc list stored the numeric value...
Common Lisp has a related problem for arrays: there are some attributes of arrays which have no printed representation. One will read an array back, but it might lack some features - like not having a fill-pointer. But atleast ARRAYP will still return true.
This seq/list thing might not be a big deal in practice, but it's another design wart. The language has in several places names, which are fundamental in Lisp and which mean something totally different now. Like 'atom'. Since the concept of a Lisp atom no longer applies - remember we have seqs, not linked conses - the name was reused to mean something different. atom used to mean (not (consp thing)) now it is something else.