I generally agree with @alexmurray’s assessment since, today, a snap must be classic so that it can drop its files into the ‘plugin location’ on the host (since that location is typically in /usr and outside of the snap’s runtime environment). snapd could be adjusted to supported this, like we do with desktop files: the snap declares something and snapd puts that something in the right place on behalf of the snap. While this methodology allows the snap runtime hurdle to be overcome, now we must consider the security of what was just done as well as how it affects the stability of the system.
In the particular case of a gnome-shell extension (note, syncrorep is a nautilus extension, not a gnome-shell extension), the extension is now running with full user session privileges in process with the shell and therefore unconfined. Considering this, the snap may as well be unconfined because the end result cannot be confined until the GNOME desktop is extended to fork/exec a new process to launch the snap under confinement (considering the design and direction of the GNOME desktop, I don’t think this will be possible). Furthermore, there is no guarantee that the extension would be expected to work on all the GNOME desktops that snapd might be running on. GNOME extensions are known to be very much GNOME version dependent and a misbehaving extension can cause all sorts of problems on the user’s desktop (though GNOME has improved in this regard AIUI, the point still stands). Since by design snapd doesn’t allow for a snap to depend on a version of a host system component, it is this last point that I think makes shipping GNOME extensions generally unsuitable for shipping as a snap.
That said, the yaru dark theme toggle extension seems relatively simple and unlikely to break the system on its own, but I don’t know that to be the case. I also don’t know how desktop-version-dependent it is. All other points stand.
My understanding of nautilus extensions like synchrorep is they operate differently than GNOME in that nautilus runs them out of process. It may be possible for snapd to be extended to take the nautilus extension that is declared in the snap.yaml, create a shell wrapper on the fly that calls out to the snap’s nautilus extension code under confinement, then puts that wrapper into the right place (all without any modifications to nautilus itself). AIUI (please correct me) is that nautilus extensions are not typically distributed via package management, and that instead they are more normally installed per-user in $HOME. This might be because admins don’t want nautilus extensions installed system wide. If this is the case, we may not want to put the effort into supporting nautilus extensions since the larger community prefers users to install them in $HOME.
In the case of GNOME search providers that @alexmurray mentioned, my understanding was that the desktop team was going to adjust GNOME to run the search providers under snap confinement along with extending snapd to put the providers in the proper location. I’m unfamiliar with the GNOME search provider APIs, but at the very least, a crashing search provider shouldn’t affect the stability of the desktop.
For context, another example is man pages. We said that we would not extend snapd to install man pages until man was hardened against arbitrary input, which has happened and now man supports both seccomp and apparmor confinement (on Debian-derived distros). Untrusted man pages can be installed on the system with the understanding that the man command is running under confinement, the pages won’t affect the stability of the system and they aren’t expected to break cross-distro.