depending on whether or not the code does something like in these examples
Because the compiler cannot always know when data is being accessed “this way”.
As things currently stand, the compiler is allowed to assume that, for the following code:
struct foo{ int const x; };
void some_func(foo*);
int bar() {
foo f { 123 };
some_func(&f);
return f.x;
}
bar will always return 123. The compiler may generate code that actually accesses the object. But the object model does not require this. f.x is a const object (not a reference/pointer to const), and therefore it cannot be changed. And f is required to always name the same object (indeed, these are the parts of the standard you would have to change). Therefore, the value of f.x cannot be changed by any non-UB means.
Why is it reasonable to have this pseudo-function for punching a hole in formal language semantics
This was actually discussed. That paper brings up how long these issues have existed (ie: since C++03) and often optimizations made possible by this object model have been employed.
The proposal was rejected on the grounds that it would not actually fix the problem. From this trip report:
However, during discussion it came to light that the proposed alternative would not handle all affected scenarios (particularly scenarios where vtable pointers are in play), and it did not gain consensus.
The report doesn’t go into any particular detail on the matter, and the discussions in question are not publicly available. But the proposal itself does point out that it wouldn’t allow devirtualizing a second virtual function call, as the first call may have build a new object. So even P0532 would not make launder unnecessary, merely less necessary.