Rationale for providing "equal?"-like "equals" method for gnu.lists.Pair

Rationale for providing "equal?"-like "equals" method for gnu.lists.Pair

[Panicz Maciej Godek]

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