It is unfortunate that the functions eq, eql, equal, equalp appear
(probably falsely) to be all of a kind, arranged along a certain
one-dimensional space of generality of equality.  In fact, equality is
a complex multi-dimensional space with very different shape depending
on the purpose.  For example, equal-as-expression-structure,
equal-as-lisp-semantic-expressions, equal-as-fortran-semantic-expressions,
equal-as-paperweight, equal-as-cook, equal-as-typist, equal-as-friend,
even if all generic, are not linearly arranged.  And they may be BOTH
type-dependent AND as each a different "application" of equality (to use
Barry's term) also application-dependent.

Some of this is just so much abstract philosophy, but the concrete
importance is: It is, to many, a letdown not to be able to customize
EQUAL because everyone likes to think themselves and their
application-of-the-day as the center of the universe.  Programmers
must not get into a turf war trying to redefine the meaning of the one
and only one EQUAL because there is not one and only one single
meaning of equality.  And the attempt to shoehorn things into one
function is what causes this.

I took the controversial position of asking that EQUAL not be included in
the language because of the confusions it evokes.  Doubtless most people
are just as happy I lost this argument because there is something handy
about the vague bluntness of EQUAL and EQUALP.  And maybe it's just as well
these names are taken by something not very general because it means that
the name isn't empty-and-waiting-to-be-pounced-upon.  But don't confuse
the notion of a "blunt" EQUAL with the notion of a "general purpose" EQUAL.
Hammers are useful for a great many household needs, too, but not all of
them are good style that you would build layered product upon...  Production
techniques, to be of refined and reliable quality, often have to develop
their own "hammer-substitutes", that is, their own more-appropriate tools.