1.1 can be done without any code but 1.2 makes std::start_lifetime_at <T> (p)
retain the memory bit representation as initial value of the object?  The
paper mentions std::launder (ick), but I'm not sure how this is implementable
at all if not sufficiently restricted.

See for example PR101641 where even existing cases are currently impossible to get right.  So the only way to make std::start_lifetime_at <T> is to somehow
emit a hard memory barrier for the compiler _and_ make sure the underlying
storage is address-taken.  Note this barrier has to prevail in RTL as well
(I think std::launder is broken in this regard).

.

Do we really need to do anything at all (except defining the new stuff in a header), or possibly using __builtin_launder in it?
I mean, my understanding of the start lifetime as something is as if with -flifetime-dse=1 there was a call to a constructor which just did nothing at all (like e.g. the struct X { int a, b; }; constructor does).  And when we inline such an constructor, there is no CLOBBER and no code at all, so in the end nothing.
__builtin_launder is just an optimization barrier (and indeed it can look like the address escapes).

I think PR101641 is just bad example, we do allow type punning through union, but only if we can see it being done.  The testcase is trying to change active union member through just a store through a pointer to union member, that is not what we support I believe.