This isn't my example, but consider this situation: you are maintaining an old code base that has stuff from 30 to 40 years ago in it because it's still working

This isn't my example, but consider this situation: you are maintaining an old code base that has stuff from 30 to 40 years ago in it because it's still working and still making the company money. But it is old, came from before we understood dependency management, and came from before we had tests as a standard practice. Parts of it have to be built on some old compiler because no one has taken the effort to rewrite it and get it to work on the new compiler. This hasn't been done because millions of developer hours have been put into it and it could take hundreds of thousands of developer hours to redo it. An obvious first step is to start by writing tests, and when you do so you can build little pieces of the old code on the new compiler but sometimes it produces wrong answers. If the old compiler worked a certain way and the new compiler works a different way it is often because the new compiler has a better optimizer and leverages better understandings of the assumption that most developers make. But some "clever" developer from back in the day did some shenanigans and leveraged undefined behavior that happened to do what they wanted. The maintenance options are either to leave it on the old compiler, rewrite the whole thing and hope you make it work right, or use std::launder to make the undefined behavior go away and hopefully make a minimal changes to retain the old behavior. In this case launder is a middle path that hopefully lets maintainers keep most of the old code with the new platform, but hopefully without having to rewrite a huge amount of it.