Simon Schröder wrote: I just recently learned that Qt has QPointer which does exactly this
This is interesting. I suspect that it depends on everything being derived from QT base classes but I am interested to know how it handles attempts at using QPointer for cross thread references to singly owned objects.

Simon Schröder also wrote: The only use case for this type (as I see it) is to use ptr_to_unique as member variable. This is the only use case where in a single threaded context (or multi threaded, but the other threads don’t have anything to do with this unique_ptr) the pointer can be zeroed out while the ptr_to_unique still exists. (Other use cases could be global or static variables. I’m not sure these are the correct motivation.)
Yes class members are going to be the principle use case for ptr_to_unique because they can persist while other things happen including deletion of the object they reference. In my own code it is typically a member of a class containing a dynamic collection and it references a particular object within that volatile collection. The class persists for a long time in an event driven environment while many things can happen to the collection within it. I use it a lot so that screen painting routines have direct access to the data they need (if still valid) and don't have to go looking for it. It is a vital optimization to prevent screen lag.
More rarely you might want to use it within a function if that function or something it calls could delete the object it references. It is only useful though if you test it again after each time you expose its lifetime to risk.