I understand the desire to use snaps inside docker containers, but really the concept of a strictly confined snap is a bit at odds with docker best practices. A snap is itself basically already a container, but implemented in different ways that docker works and so to run snapd inside a docker container is basically to run dockerd inside a docker container which is an anti-pattern. Instead what most folks end up doing when they find themselves wanting to run docker-in-docker is really actually to mount the docker socket inside the docker container so that docker-in-docker really is talking to the host docker, bypassing all of the confinement of the docker container and also exposing a very large security hole, not to mention the ability for a docker container to modify the host system in arbitrary ways.
We do not have any plans to officially support running snaps inside docker because any such solution right now would effectively end up having snapd inside the docker container control/effect the host and that is not something we are interested in maintaining.
For a more concrete example, take something like the a mongodb snap. If we have a docker container running snapd that installs mongodb as a snap, it will try to load apparmor profiles for mongodb snap onto the host, and this will conflict with any potential mongodb snap that the user has installed on their host system outside of the container, this breaking one of the fundamental desirable properties of containers, that they are isolated from the host
Please note that the reason we do not support snapd inside a docker container is not just systemd but also the confinement as detailed above. Docker containers do not get run inside their own apparmor namespace, unlike LXD where LXD containers are run inside their own apparmor namespace allowing snapd to create and mutate apparmor profiles that are isolated from the host system.