Indeed. And even with my lack of clang expertise, it's clear that this would be highly nontrivial to change in clang and probably some other compilers. It's clearly not a change that we should make lightly. On the other hand, that also makes it more urgent to address the issue, since compilers currently still seem to stop short of applying the rule in situations where it would interfere with real code.
I would personally still favor a more usable and intuitive model in the long term over implementer inconvenience in the short term. Implementations are easier to change than client code. The compiler problems are hard, but coming up with alternative parallel algorithms, or teaching tens of millions of programmers a needlessly complex rule, is almost certainly harder.
This seems to be a case where we currently have an unintuitive rule (at least to most people) that introduces UB that seriously gets in the way of applications (and in my opinion teaching), without a fully convincing argument to justify the rule. Especially given the general complaints about UB in C and C++, I think we should avoid such cases. I'm perfectly willing to accept UB in other cases, like signed integer overflow, where it gives useful implementation freedom and demonstrably helps optimizers. Here I think we basically have an unproven conjecture that it might eventually do the former (via potentially making use-after-free easier to detect) and some really obscure, and to me unconvincing, examples of the latter.
My conjecture (real information welcome!) is that current compilers tend to conflate compiler optimization facts like "*a aliases *b" or "a and b point to the same thing" with the result of the expression "a == b". The current standard sanctions this, but fundamentally they're not the same. When the compiler asks aliasing questions, it generally wants to know whether an update through one pointer could affect the value pointed to by the other. It doesn't care what answer it gets if either side cannot be safely dereferenced. We now have lots of examples where user code does care about that case.