@dclane, having thought about it some more, I wish I’d never mentioned the possibility of splitting the snap into “classic” and “confined” parts.
There are trade-offs, and splitting the snap content doesn’t help.
The Wayland compositor (the bit that is a candidate for “confined”) needs to know which processes can be trusted to provide parts of the desktop (panels, x-server, launchers, wallpaper, …). Where processes can be launched directly by the compositor it is possible to track their pid (this is what Miriway does now) and, as they are direct clients, this works well enough.
However, some of these components (those that launch apps, or serve X11) need to be “classic”. And launching them via desktop-launch means, in essence, that the compositor needs to trust any connecting process to provide parts of the desktop (not just ones from the classic snap).
There are some additional problems providing the environment needed to start Xwayland that I don’t see a way to resolve. (E.g. the compositor needs to create the X11 socket and identify the FD as a command-line option.)
This is, of course, “all software” and it would be possible to move large chunks of the compositor into a process in the classic snap, but this would then need a rich communication channel to interact with the part that remains confined. I think this is beyond a feasible amount of work.