`NoDestructor` just ensures that the destructor is not called on the wrapped object, but you still need to manage the lifetime. If you look at the example, its recommended usage is with a function static. In other words, it's a utility to implement leaky Meyers' singletons.
std::launder is a bit weird here. Technically it should be used every time you use placement new but access the object by casting the pointer to its storage (which NoDestructor does). However, very little code actually uses it. For example, every implementation of std::optional should use it? But when you do, it actually prevents important compiler optimizations that make std::optional a zero-cost abstraction (or it did last time I looked into this).
std::launder should probably be used more than it is in low-level code if you care about correctness, even though it doesn’t always bite you in the ass. It is a logical no-op. std::launder is a hint to the compiler to forget everything it thinks it knows about the type instance, sort of like marking it “volatile” only for a specific moment in time.
The use of std::launder should be more common than it is, I’ve seen a few bugs in optimized builds when not used, but compilers have been somewhat forgiving about not using it in places you should because it hasn’t always existed. Rigorous code should be using it instead of relying on the leniency of the compiler.
In database engine code it definitely gets used in the storage layers.
std::launder is a bit weird here. Technically it should be used every time you use placement new but access the object by casting the pointer to its storage (which NoDestructor does). However, very little code actually uses it. For example, every implementation of std::optional should use it? But when you do, it actually prevents important compiler optimizations that make std::optional a zero-cost abstraction (or it did last time I looked into this).