The TBAA violation was known when the paper was approved by LWG.

@jwakely , do you think there is anything we can do to this note to make it palatable?

I think this is why we used "can be" rather than "is" - it can be viable on non-TBAA implementations. For some implementations it's not a viable implementation strategy, whether because of TBAA or something else (e.g., void* might not have the same size and alignment as Pointer).

The main motivation for that member is to interoperate with APIs doing disgusting aliasing violations. The motivating examples in the paper involve aliasing violations, but that doesn't happen inside the standard library. If users choose to pass the void** to something that misuses it, that's not the library's problem, and it's exactly what they'd be doing today without the std::out_ptr utility.

The main motivation for that member is to interoperate with APIs doing disgusting aliasing violations. The motivating examples in the paper involve aliasing violations, but that doesn't happen inside the standard library. If users choose to pass the void** to something that misuses it, that's not the library's problem, and it's exactly what they'd be doing today without the std::out_ptr utility.

We intentionally worded this to make the behavior well-defined even for what would otherwise have been disgusting aliasing violations though - that's why we didn't just specify this as returning the result of reinterpret_cast.

Can we add "for some compilers" to indicate that such strategy is not always viable?
Users may write analogies of these types, IMO it should be noted that the strategy is not portable.

We tend to avoid the term "compiler" in the standard; some of the existing uses would benefit from replacement by "implementation" or similar.