If you are referring to the (second) destruction happening automatically for the materialized temporary, it's an explicit issue only for the objects with non-trivial destructors. I'd say this is no different from a more simplified example:

{
  int i;
  i.~decltype(i)();
}

The above code is fine, since no non-trivial destructor for int exists. Clang indeed denies it constant-evaluation, though.

If you are referring to the (second) destruction happening automatically for the materialized temporary, it's an explicit issue only for the objects with non-trivial destructors.

Yes. I think the status quo is that double destruction of int is well-defined.

However, it seems to me that [basic.life] p9 is nearly redundant, since [class.dtor] p18 covers almost all (if not all) of such cases. And [class.dtor] p18 states that UB happens even if the destructor is trivial - but pseudo-destructors are not covered.

Moreover, I'd say [class.dtor#18] itself is redundant in a normative sense. Basically, there are two substatements:

Once a destructor is invoked for an object, the object's lifetime ends

Already stated in [basic.life#1.4].

the behavior is undefined if the destructor is invoked for an object whose lifetime has ended

Already stated in [basic.life#6.2]/[basic.life#7.2], since destructors constitute non-static member functions.

This definitely seems unclear to me.

• [basic.life]/4 and in general the fact that it seems meaningless to end the lifetime of an object whose lifetime has already ended suggests that destroying an out of lifetime object is always UB.
• [basic.life]/7.2 suggests that destroying an object of class type that's out of lifetime is always UB, because it always invokes the destructor.
• [basic.life]/10 suggests that it's UB to implicitly destroy an out of lifetime object (only) if it has a nontrivial destructor.

For what it's worth, in the context of P0593 I think the most logical thing would be to say that it's UB to destroy an out of lifetime object

[diff.cpp17.basic]/1 also suggests that P0593 intended for this to be UB, but perhaps more wording cleanup is necessary to get us there.