You should not override equals and hashCode so that they reflect the mutable member.
There are two reasons:
first: because this would break the contract of hash code:
Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer...
@see: JavaDoc Object#hashCode()
second: technical vs. business logic
If you break that requirement HashSet and HashMap and every component based on them will probaly not work correct.
The second reason not to do this: is more my personal point of view. I think hash code and equals are technical terms that should not be used to implement business logic. Imagine: you have two Objects (not only Collections) and ask if they are equals, then there are two different ways to answer them:
technical: the are equals if they represent the same object, which is different from being the same object (if you think of proxies, serilization, remote stuff...)
bussines logic: they are equals if the look the same (same attribute) – the important thing here is, that there is not the holy one definition of equality even to the same class in even one application. (Sample question: when are two stones equals?))
But because equals is used by technical stuff (HashMap), you should implement it in a technical way, and build the business logic related equals by something else (something like the comparator interface). And for your collection it means: do not override equals and hashCode (in a way that breaks the technical contract).