First of all it is debatable over whether or not the spec allows (eq x x) to be false. eq is required to return true if the arguments are the same identical object. It would be a twisted interpretation of that to allow (eq x x) to ever return false.
Now (eq 1 1) is specifically not required to return true, as, for example an implementation that boxes all numbers could create two separate objects for that expression, and the arguments are now in fact not the same identical object.
This is something that exposes implementation details to the user, so using eq is discouraged (and in fact it can only portably be used to compare symbols). There are times when the best way to accomplish what you are doing is to (ab)use implementation specific behavior, and this is particularly true of Lisp which was a dynamically typed garbage collected language in the 70s (yes, predating the VT100 terminal referenced in this article).
Direct quote from Common Lisp HyperSpec, under Function EQ:
"An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. "
It is strange for (eq x x) to be false, when x holds 1, or anything else; yet that appears to be allowed when it holds a number or character.
(eq 1 1) being nil caters to implementations that have heap allocated numbers. That is fine, but under (eq x x), both arguments should be the same heap-allocated 1.
(eq x x) being nil is nothing but pandering to some weird, historic implementations, whose quirk should never have been made ANSI conforming. I don't think it's relevant today.
First of all it is debatable over whether or not the spec allows (eq x x) to be false. eq is required to return true if the arguments are the same identical object. It would be a twisted interpretation of that to allow (eq x x) to ever return false.
Now (eq 1 1) is specifically not required to return true, as, for example an implementation that boxes all numbers could create two separate objects for that expression, and the arguments are now in fact not the same identical object.
This is something that exposes implementation details to the user, so using eq is discouraged (and in fact it can only portably be used to compare symbols). There are times when the best way to accomplish what you are doing is to (ab)use implementation specific behavior, and this is particularly true of Lisp which was a dynamically typed garbage collected language in the 70s (yes, predating the VT100 terminal referenced in this article).