I just learned of P2815, and I do not know of another place I can respond to it, so I'm going to answer here.

In my opinion, the proposal in question eliminates all provenance based alias analysis, used to eliminate memory accesses when unanalyzed code is present. 

Consider the following example code:

int foo(int* p){
     int i;
     opaque_operation(&i,p);
     i = 0;
     *p = 1;
     return i;
}

(Where the optimizer is unable to analyze `opaque_operation`
In current compilers, this can be optimized to calling `opaque_operation`, writing `1` to `p`, and then returning `0`. Under the proposal, however, `opaque_operation` could observe that `&i` and `p` have the same *value representation*, which means that they must be equal (it may do so with defined behaviour in all executions, for example, by terminating if they are bytewise unequal). Thus the write to `p` may modify the value of `i`. This would make the transformation to:

int foo(int* p){
    opaque_operation(&[rsp],p);
    *p = 1;
    return 0;
}

invalid under the proposal.

In my opinion, this extends to basically all similar transformations, which is the majority of provenance-based alias analysis. 

Further, it means that a non-volatile read as a character type (which may then be used to test the value representation) cannot be optimized away when applied to an unknown object (because that object may contain a pointer). In particular, a discarded `memcmp` is now able to alter the behaviour of the program, despite previously being able to be elided because the function is pure. 

Link to the proposal in question: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2815r0.pdf.