Hilaire,
as soon as the hash of an object changes because you change an attribute that is used in the hash function, the object is not identical to its older ego any more, so Voyage cannot know it still is the same object (nor any other caching solution).
Or am I wrong about this whole hash/= thing?
Yes :) You are mixing equality and identity. An object is identical if the memory location is the same. An object is equal whatever is defined in =/hash. In the default case classes do not overwrite =/hash so = and == return the same value. If you change the state of an object you might change the hash but not the identityHash. So it is identical but different to the version in the database hence should update the existing object and not creating a new one.
The only thing I could imagine is that Voyage somewhere uses = where it should use ==. But wouldn't many more people have problems then?
The problem is that we often use equality based collections where we should use identity based ones. These problems are hidden because = and == are the same for normal classes. As soon as you overwrite =/hash you experience problems because of that.
So I have the impression that in general overwriting =/hash is not a good idea. Most of the time you mean "equal regarding to some context". In this case it is better to have your own equality selector like #isSameX:, #hasSameX: etc. Because the kernel classes rely on = equality you tear the semantics apart if yoou overwrite.