snapd and WSL mysteriously fails

Seriously, why now, not back then?

So we have a new wrinkle in using snaps under WSL, which I ran into while experimenting with the new native systemd support in recent WSL builds. Unfortunately, I don't think they have anything to do with the native systemd support, as I had snaps running under it just fine (once solving the need to mount securityfs under it, which was not necessary under the systemd hacks) for a while.

But then this happened:

❯ snap list Interacting with snapd is not yet supported on Windows Subsystem for Linux.
This command has been left available for documentation purposes only.

I am very puzzled as to why this started happening now, as so far as I can tell it was introduced 'way back in the day, in this commit from 2018 - sanity: refuse to try to do things on WSL. · snapcore/snapd@1adae13 - which we should in theory have been saying since all the way back in snapd 2.37. (My current Debian installation has 2.57.4, and when I checked, 2.37's been in Debian since bullseye.)

And yet happening now it is.

Ironically, while this prevents snap from running, and thus snaps being managed, and leaves systemd degraded because snap won't run in snap.seeded.service, the snaps themselves actually work just fine.

❯ which hello
/snap/bin/hello

❯ hello
Hello, world!

There's a PR open to remove this check - https://github.com/snapcore/snapd/pull/12179 - but if you see the problem in the meantime, that's where it is.