Are isomorphic structures EQUAL?

I don't want to reopen the discussion that we had about equality a
while back, but someone in my group just tripped over an ambiguity in
the manual.
She was using DEFSTRUCT with the (:TYPE ...) option and using EQUAL to
compare structures and everything worked fine since EQUAL did a
component-wise equality test.
Then she got bold and decided to let DEFSTRUCT choose the
representation, so she left off the (:TYPE ...) option. Low and
behold, EQUAL did not do a component-wise equality test, it tested for
EQL!
So she looked at the def. on page 80 where it said "Certain objects
that have components are EQUAL if they are of the same type and
corresponding components are EQUAL." Unfortunately, the rest of the
definition did not make it at all clear whether or not objects created
by DEFSTRUCT were among these "Certain objects". Looking on the next
page at the def. of EQUALP (which happened to do a component-wise
equality test), she read "Objects that have components..." The only
difference was the word "Certain"!
So we tried it on another CL (SymbolicsCL), and got the same behavior
(as with VaxLisp). Which leads me to almost believe that EQUAL NOT
supposed to to a component-wise test for equality. Except...
What happens to implementations that want to represent structures
using plain old vectors? How will EQUAL distinguish vectors from
structure-vectors?
This interaction of DEFSTRUCT/EQUAL is going to cause a lot of bugs.
People are going to prototype structues using the (:TYPE LIST) option
and use EQUAL to do equality tests. Then when they remove the :TYPE
option, KaBoom!
There will be no way to do a component-wise test (using EQUAL on each
component) on two structures unless one writes a structure-specific
equality predicate.
Therefore, I propose that two structures of the same type that are
created by DEFSTRUCT (regardless of the :TYPE option) be tested for
equality component-wise and that the CLtL make this clear.
Until then, she can get by with EQUALP (since her structures don't
conatin strings, floats, etc.).
-- Nick