C++ already gives us a tool for pointer zapping

Well, yes, that is the main problem here, which is why I think (3) is totally impossible to implement (outside of CHERI) without something like pervasive runtime provenance tracking. But I'm still not convinced that (2) is impossible. It "just" requires the compiler to look at every pointer comparison and break it down into one of four cases:

1. We can statically prove that the pointers have the same address and overlapping or identical provenances. Fold it to true.
2. We can statically prove that the pointers do not have the same address, or have non-overlapping provenances. Fold it to false.
3. We can statically prove that if the pointers have the same address, then they also have overlapping or identical provenances. Emit a comparison instruction.
4. We can't statically prove any of the above. Insert provenance barriers for both operands, which only apply prospectively to these exact variables (i.e. calling functions don't have to know we did this unless we return one of the pointers, in which case we were already in the business of more complicated escape analysis anyway), and then emit a comparison instruction.

(3) sounds weird, but it probably happens fairly often (if both pointers are known to be valid-or-else-UB-happened, if both pointers came from the same array as in a simple for loop, etc.). Meanwhile, if we're in case (4), then I find it hard to believe that we're really losing much performance from the optimization barriers anyway. And (4) is pessimistic anyway. If you can prove that one of the pointers is valid-or-else-UB-happened, you probably don't need to insert a provenance barrier for that pointer at all. The set of optimizations we're losing here looks really, really small to me, but maybe I just don't understand how compilers work.

On CHERI-with-rich-pointer-comparison, you can replace both (3) and (4) with "We can't statically prove either (1) or (2). Emit a comparison instruction," since in that case the hardware will already DTRT anyway. For that matter, you can *also* do that in any implementation which does not have provenance, since it is semantically equivalent to inserting provenance barriers "everywhere."