My point was exactly that the allowed usage you propose, where Emacs Lisp is a Lisp and Clojure, for instance, is not, is quite ridiculous. The disallowed usage, "Which Lisp should I use, Clojure or Common Lisp?" is however, not ridiculous. Your rule excludes a meaningful usage and includes a ridiculous one.
I'm not saying that Common Lisp reduces to s-expressions and syntax extension or even that "lispness" does, only that s-expressions and syntax extension are the features to which the denotation "a lisp" most frequently refers.
Incidentally, I program in Common Lisp for a living and am the author of several libraries in several lisp dialects, which, while not enjoying much use, do demonstrate a working knowledge of the language family. But thanks for imputing my qualifications.
But the question "Which Lisp" is entirely meaningful, more so than even the question, more acceptable by your definitions, "Should I program in in Emacs or Common Lisp?" The programmer asking "Which Lisp?" might very well find that Racket is the language he wants or that Clojure is, since both are similar in capabilities to Common Lisp. The question meaningfully indicates confusion. A person wants to write a real program in a language with s-expressions and a macro system, probably, and any of the languages listed satisfies those goals, and the discussion will focus on the ways they differ. This seems fine to me.
I find this to be unnecessarily prescriptive, as are almost all purely semantic assertions about what should be (semantic used in its weak, normal language sense here). It is certainly true that Schemes and Clojures and Adders and Emacs Lisps and so on differ in many respects from "Common Lisp" but that hardly justifies fixing the label "Lisp" to refer only to Common Lisp. I mean _Emacs Lisp_ contains Lisp in its name! Would you claim Emacs Lisp is not a lisp?
It remains that these languages have more in common with one another they they have in common with, say, Ada or Standard ML, but even were it not the case, so long as a listener understands what a speaker means when they refer to a language as being "a lisp," I see no problem with the continued usage. Language works when it allows communication, and as long as a word clearly denotes a concept in common parlance, it hardly needs to be dictatorially controlled. If people were referring to Clojure as a "Common Lisp," it would be useful to correct them, but this is not the case.
Vague language can even be enlightening, as it forms the nucleating body for useful discussions. For instance, one might pose the question "Is Ruby an Acceptable Lisp?", and while the answer is obviously, stridently, hilariously, no, the discussion will help illuminate what both terms mean.
So I favor letting language do its job, and letting lisp continue to refer, as an improper noun, to a cloud of languages sharing a family resemblance.
I'm not saying that Common Lisp reduces to s-expressions and syntax extension or even that "lispness" does, only that s-expressions and syntax extension are the features to which the denotation "a lisp" most frequently refers.
Incidentally, I program in Common Lisp for a living and am the author of several libraries in several lisp dialects, which, while not enjoying much use, do demonstrate a working knowledge of the language family. But thanks for imputing my qualifications.