Yeah, the real question is whether LLVM might find it useful to use aliasing to inform comparisons at some point in the future. It seems plausible to me, but ultimately it’s hard to know.
It seems fairly clear to me that there are more operations on unsafe pointers that ought to have been unsafe: casting them and, now, comparing them. We have discussed the idea of phasing in these rules by making a lint that warns if such operations are performed outside of an unsafe block (which perhaps eventually graduates to an error at some point). What is needed though is a strong justification: the possibility of undefined behavior could be such a thing.
One concern that I always have in these situations though is that I want rules for undefined behavior that match what programmers actually do and sort of expect to work. This is why, for example, I find C’s strict aliasing rules unfortunate, because I think they violate most people’s mental model of how the computer works and what should be allowed. Basically, people should be able to think of the machine as a kind of simple turing machine that runs along and loads and stores data, and strict aliasing rules break that. Put another way: it’s not enough that, in the event of a crash, we know there was unsafe code involved. Ideally, there’d be no crash in the first place. 
Along those lines, it does seem to me that having free magically transmute the freed pointer into undef would be rather surprising. That is, I could imagine people trying to do wicked tricks in unsafe code like:
free(x);
let y = malloc(...);
if x == y { /* actual aliasing occurred! recover from some annoying situation */ }
but I don’t really have an actual example of how this could be useful.
Anyway, I’m mostly just musing out loud here at the moment.
