Note: The information in this answer has been validated against WSL 1.2.0 and Docker Desktop 4.18.0. The methods discussed below have changed in the past and will likely change again in the future.
In a WSL2 distro - what determines the files that appear under: /wsl/{some-other-distro}
The question title is a bit ambiguous. I believe you are asking about /mnt/wsl/{some-other-distro}, but you left out the /mnt part. Or you could be asking about the \\wsl.localhost\<distro> share (a.k.a. \\wsl$\<distro>).
For the latter, the rootfs for the distribution is provided as a share through \\wsl.localhost (the now-preferred version over the deprecated, but still available, \\wsl$\).
For /mnt/wsl, there is no automatic process for this - Each distribution (and even the end-user) can mount whatever they like under /mnt/wsl. Docker chooses to do so in its startup, but you can also create your own mounts using something like my answer here.
For /mnt/wsl itself, there are a few files that WSL automatically generates there so that they are available in all distributions:
resolv.conf - The automatically generated resolver configuration, which is then symlinked into /etc/resolv.conf.
(In the latest versions of WSL): /mnt/wsl/run and /mnt/wsl/user which are then bind-mounted into their respective directories.
Why do I not see the entire filesystem at /mnt/wsl/docker-desktop-data in my Ubuntu WSL2 distribution?
In a running distro - how is /mnt/wsl/docker-desktop-data different from /some/mount/path after you have mounted docker-desktop-data to it manually with sudo mount -t drvfs '\\wsl$\docker-desktop-data' /some/mount/path? I can clearly see more of the filesystem in the latter.
As you've noticed (or at least assumed), Docker Desktop does not mount the virtual drive for docker-desktop-data itself. Instead, it creates a bind-mount to a subdirectory of that drive (and a number of other bind-mounts to other subdirectories). At a high level, docker-desktop-data seems to use a technique similar to the one in my answer on sharing files between distributions, in that, when starting up, it creates a bind-mount for the primary "shared directory."
From a regular WSL distribution, you can see the actual mount with:
$ findmnt | grep "version-pack-data\s"
| |-/mnt/wsl/docker-desktop-data/version-pack-data /dev/sdf[/version-pack-data] ext4 rw,relatime,discard,errors=remount-ro,data=ordered
In this case, dev/sdf has been assigned to the virtual drive for the docker-desktop-data distribution. That may change depending on the order in which you start distributions (and how many).
If we could access the docker-desktop-data distribution directly, that would be the equivalent of running (as root):
mount --bind / /mnt/wsl/docker-desktop-data/version-pack-data -o X-mount.mkdir
And while you may already know this, for other readers, note that /mnt/wsl is a tmpfs that is created by WSL itself on each startup. It is shared and accessible in all WSL distributions, and it is ephemeral -- Its contents (the mountpoints, not the data under them) will be removed each time WSL shuts down.
What determines what files will and will not show up in that mounted directory?
With the above in mind, it should be apparent that what you see in /mnt/wsl/docker-desktop-data is a combination of each of the bind-mounts, with the primary one being version-pack-data.
With a full findmnt, you'll notice a number of other docker-desktop-data mounts as well. While reverse-engineering each of these is beyond the scope of any one answer, there are a few interesting ones. From inside docker-desktop, run:
mount | grep iso
This will show you how Docker delivers the executables and libraries themselves. These ISO's can be found in the Windows Docker installation folder (usually C:\Program Files\Docker\Docker\resources). When a new release of Docker comes out, the ISO files are updated with the latest versions and then mounted into WSL.
Side-notes:
You'll notice that the mount command only shows /dev/sdf being mounted on /mnt/wsl/docker-desktop-data/version-pack-data. The same thing would happen if you created a bind-mount yourself in your preferred distribution. E.g.:
$ sudo mount --bind /home /mnt/wsl/test -o X-mount.mkdir
$ mount | grep home
# Doesn't find anything
$ mount | grep test
/dev/sdc on /mnt/wsl/test type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)
However, you'll get better info from findmnt (as above) or:
$ cat /proc/self/mountinfo | grep home
1734 71 8:32 /home /mnt/wsl/test rw,relatime shared:501 - ext4 /dev/sdc rw,discard,errors=remount-ro,data=ordered
As you may have realized by now, it's probably better to mount the docker-desktop-data drive as a native ext4 rather than using drvfs:
$ findmnt -a | grep "version-pack-data\s"
| |-/mnt/wsl/docker-desktop-data/version-pack-data /dev/sdf[/version-pack-data] ext4 rw,relatime,discard,errors=remount-ro,data=ordered
# Using the block device returned (sdf in this case):
$ sudo mount /dev/sdf /mnt/wsl/instances/docker-desktop-data -o X-mount.mkdir
$ cd /mnt/wsl/instances/docker-desktop-data
This will provide native permissions, symlinks, etc.
In the latest releases of WSL, more exploration can be performed from the root namespace, a.k.a. the Debug Shell. In an administrative PowerShell, run:
wsl --debug-shell
This root namespace shows all running processes in each of the distributions, including docker-desktop-data.
There's only one process running in docker-desktop-data (other than the default init and Plan 9 server, and that's wsl-keepalive. I'm going to assume the obvious given the name -- That this is simply a long-running process to keep docker-desktop-data running and accessible.
You can demonstrate this with (again, in the debug shell):
$ cat /proc/$(pgrep wsl-keepalive)/environ | xargs -0 -I{} echo {} | grep WSL_DISTRO_NAME
WSL_DISTRO_NAME=docker-desktop-data
You can also explore the other distributions namespaces with lsns, nsenter, and others. However, note that the lack of a shell or any other executable in docker-desktop-data seems to preclude using nsenter to explore that particular namespace. However, exploring the /proc/<pid> for that that distribution can still be interesting.
sudo lsin Ubuntu ?