Well I can think of several options…
Option 1 : save differently. In the original post you mentioned how you were recreating the objects upon reloading as you knew pointers would be rubbish. This is kinda the same issue. Instead of trying to store objects and pointers, store the data required to recreate those objects. I believe this is the standard go-to solution when other developers need to do this kind of thing.
Option 2 : use GameState. Don’t move your objects to the GameInstance when switching levels. Save them before map load, let them be destroyed, and reload them after map load. This might only work if the map and gamestate are always the same though.
Option 3 : upgrade the serializer to fix paths dynamically. The way FObjectAndNameAsStringArchive works is really simple, nothing to be scared about. Whenever it encounters an object pointer to save, it saves object->GetPathName() instead. Upon loading, it reads that string and uses FindObject/LoadObject to find the actual object.

With a bit of additional code, after spawning the master object, you could get its path (eg. /Engine/Transient.UnrealEdEngine_0:MyGameInstance_C_1.MasterStateObj_1), then replace the old root path with that new root path before using FindObject.
Option 4 : as a matter of fact a while ago I did experiment with making my own serializer to do this sort of things. It might do exactly what you’re trying to do. It’s a bit rushed, not documented, and barely tested though so there could be bugs remaining. But not the bugs already discussed here. Actors and components deserialization are a pain and probably not very solid, but for UObjects I’ve had satisfying results.
The system works differently - it takes a single “root” object as input and serializes that object along with all its subobjects into a file. Subobjects are discovered automatically while traversing and serializing UObject* properties. It’s designed to properly resolve all internal references upon reloading, while references to external objects will obviously suffer the usual caveats.
The outer of the root object is intentionally not serialized as it would typically be an external reference which the user (developper) should specify upon reloading.
Usage looks like this :
But usage should be easily adaptable, such as putting the resulting array of bytes into a SaveGame property rather than directly saving to file.
