You do have to check if a soft ptr is already loaded into memory or not, in which case you must load it either sync or async. It might still be in memory now because you just switched the property type but you need to implement loading in the code where you use it.
You can never really get this right because it is so project specific. I think it will be amazing in a game like RE Village where nothing really looks the same cause it’s so hyperreal. I wouldn’t want to make 200 tombstone blueprints for such game and would really benefit from a good editor extension to edit them.
Quite possibly it is more of an editor extension, or an automation feature, than a tombstone specific system and that is why it might feel overkill for the tombstone alone.
Technically, if you want every single stone to be different and have the most manual control then you could nest blueprints or meshes from the outliner panel on the level
From there you can access the public / editor panel properties on all the attached items. Since it’s a stone normally holding no logic, this should be sufficient in most cases and you wouldn’t need to put the “editor logic” inside the stone or add components to that stone’s asset.
You might also have found various cases where you prefer your configuration system to be asset specific, maybe to do things in the construction script.
There’s no solution to fit every project but there are a few traps you can run into, mostly adding too much not fitting a project, or limiting a project with the new system. Best option is always to make things optional, plug and play. Or make one master blueprint which generates entire stones for you at a position as some form of editor utility, then you have only 1 blueprint asset.