Kompottkin wrote:“The consequences are undefined if literal objects are destructively modified.” As far as I can see, that's all there is to it. (Of course, it wouldn't be the first time I misread the spec. )
But you're reading the spec as if it has some mystical powers. The spec says that because it's true, but it's not true in every instance; the fact that the spec says it doesn't make otherwise well-defined (by that same spec) operations magically behave differently.
No, it's not the only thing that matters. In fact, QUOTE seems to me to be irrelevant. It's true that modifying the return value of (eval `(quote ,(list 1 2 3))) is (I believe) perfectly well-defined, but that's because in this case, the argument to quote is not a literal (while in (quote (1 2 3)), it is).
You're right, quote isn't relevant because most data types don't need it: "123" is the same as (quote "123"), etc. The identity of the object inside the (putative) quote form is what matters. There is no way for Lisp to distinguish (list 1 2 3) from (quote (1 2 3)) after the object exists (the only difference is when it comes into existence: read time vs. eval time). The reason it's "undefined" is that the file-compiler can (=necessarily must) change object identities: if it puts that list in the file, it's not going to be the same, identical, list when you load the file. But that can't happen "inside" Lisp (to stuff you type at the REPL). In other words, even if a Lisp implementer actively wanted to make destructive modification of a literal do something unexpected, just for laughs or whatever, there's no way he could do it (in general; you can catch special cases, like where it's lexically apparent...so SBCL can issue warnings, etc.)
I.e., the consequences of what is defined in the spec takes precedence over what isn't. (If I define ⊕ such that a⊕b=a+b when 6<=a<=b<=14, my spec would be correct to say "the consequences are undefined if ⊕ is applied to two integers", nevertheless 8⊕11 is 19!)