That should be known by now, indeed, never ever store pointers to non-ID data that do not belongs to same datablock. This is not supported, and we absolutely do not want to support it. At all.

Even the few cases where this is done currently (runtime-only, like e.g. object's pose storing pointers to armature's bones) are already a pain to handle in libdata management code.

So yes, using names is the correct solution here. And if you absolutely need to have runtime-only pointers (for performance reasons), then add functions to easily invalidate and rebuild those. And NULLify those pointers in readfile.c. But again, even that is a pain to handle correctly everywhere, so please only do it if absolutely necessary.

Yes, seems like we can use names/identifiers. I can do this if you're not on it already?

The whole handling of the workspace view-layer has to be done rather carefully, easy to mess things up. That especially matters for the whole workspaces.blend idea. Appending a workspace from there should also somehow append settings for the viewport from this specific workspace.
I think that's exactly why I used the layer pointer in the first place: Back then my understanding was that we'd manage viewport render settings through view-layers, meaning we had to read them when appending somehow anyway. Now, what we do is storing the viewport settings directly in the workspace (which I still dislike a lot for various reasons), so indeed, now we can/should use identifiers.

I also have to admit that I was sure scene data-blocks couldn't be linked when coding this (thought only individual objects or groups could).... no idea where that came from, and I obviously also didn't double check that...