I had always assumed that TStrongObjectPtr worked similarly to TSharedPtr in that it keeps an internal reference count. But it appears that it works more like TUniquePtr in that it takes exclusive ownership over the UObject.
So if you have two TStrongObjectPtr s referring to the same UObject and one of them goes out of scope, the other one now has a dangling pointer. Unless I misunderstand the code, this is because the base class GCObject unregisters the object in its destructor.
The copy constructor and copy assignment operators of TStrongObjectPtr do not take this into account though, so it’s easy to end up in this situation.
Am I on the wrong track here? If not, those copy operations should be removed