The issue that's trying to be solved with std::launder is essentially around lifetime issues, which strict provenance doesn't really solve. Strict pointer provenance is about fixing the semantics of int-to-pointer, which requires tweaks to pointer-to-int. std::launder, by contrast, is trying to fix cases where memory is being validly reused after the language thinks the object is dead--it's the kind of thing you might need to use to implement an allocator, for example, although you already have screwy effective type rules breaking you that std::launder doesn't fix.

My point, which may or may not be entirely correct, is that the examples I've seen are, in effect, uses after a lifetime is over. They seem to boil down to something like:

    struct A {
        const int x;
    };
    
    A *ptr = <address of object 1>
    
    ... destroy object 1 and create object 2 in its place, so <old address of object 1> == <new address of object 2>
    
    do_something_with(ptr->x);

The language thinks ptr points to object 1, but it actually points to object 2. In a weak provenance model, maybe this is valid, and it gets the correct results if std::launder is used.

But it seems to me that, in a strict provenance model, accessing ptr->x is incorrect -- ptr has provenance for object 1, and object 1 is gone. The operation needed to restore access isn't something very generic like std::launder -- it's specifically the creation of a new pointer with provenance matching object 2. So you don't want:

    do_something_with(std::launder(ptr->x));

You want (very pseudo-codeish):

    do_something_with(with_addr(&object2, ptr)->x);

And I would hope that a good provenance implementation would not require an abomination like:

    do_something_with(launder(with_addr(&object2, ptr))->x);