First, a strict mode snap doesn’t have the ability to copy to /usr/share/anywhere because /usr comes from the base runtime, not the classic system.
Second, even if it could, @pedronis is right in that we would want some sort of snapd involvement to take the desktop file, sanitize it and put it in place. This doesn’t exist today and there isn’t anything for you to model your strict mode snap on to make it work today.
Third, a desktop shell is pretty specialized and we would want to think through at least the different pieces including login manager integration (this topic) and what you described in How to confine a desktop shell so we can come up with a decent solution.
OTOH, it does seem that login manager integration could be considered separately from the others… It definitely seems plausible to have some new yaml to declare one’s intent to integrate with the login manager. I think we would want that to be bound by snap declarations though, but I’m not sure a snapd interface is the correct fit (it feels more like the ‘autostart’ feature or even @jamesh session services work in that you want to register something to be startable, but otherwise don’t need any other accesses that aren’t covered by other (perhaps future) interfaces). Something along the lines of this:
is clean from a developer POV, but doesn’t integrate with our current concept of snap declarations so work would need to be done for that (ie, something like what we do for granting classic confinement is needed).
Introducing a new interface allows for using snap declarations immediately:
plugs: [ login-manager ]
but seems slightly odd in that I don’t think there will be any other backends in use other than the login-manager backend (ie, the thing sanitizing the desktop files and putting them into place). Maybe that isn’t a bad thing…
Another option is doing something implied down in
meta/login-manager/egmde.desktop, but this option makes it so we can’t regulate with a snap declaration.
Again, these are just ideas to help spark the conversation. Perhaps there are others or the ones above can be expanded to work best.
Considering the above, I think a good design is possible for how to expose this to snap developers, but the implementation may be complicated by directory placement across distros, the fact that xsessions/* and wayland-sessions/* have different content and perhaps that different login managers need different support. Is
/some/distro/path/xsessions a standard or a convention? Is the content of the *.desktop files a standard across all login managers that support the directories? How widespread is the support for these directories? Is it a Debian thing? A freedesktop.org standard?
There may be other things to consider (part of why I referenced @jamesh ) but hopefully this might help further the discussion.
 likely solvable with somewhere in the yaml: