I'd like to know what the rationale for providing the "equals" method with "structural identity" is. I found it problematic in at least one respect: I have decided to use Java's weak hash tables to represent "properties" attached to cons-cells. However, since those hash tables rely on the Object's "equals" method, the table is unable to distinguish between two different cons-cells that point to the same object. I came up with two solutions to this problem. The first one was patching the implementation of Pair, simply by removing the implementations of the equals method is LList and its subclasses. (IIRC there were some failing tests after the change, but I didn't investigate further) The second solution was simply subclassing gnu.lists.Pair and overriding its equals and hashCode methods, as I did here: https://github.com/panicz/grasp-android/blob/master/stages/stage6/src/org/scheme/parse.scm It works, but the "equal?" semantics for cons-cells doesn't seem right to me, so I wonder what was the reason for providing it, and whether there is some code which relies on it