I use WSL2 at work every day, and in fact I try to do as much work in it as possible. It's absolutely riddled with problems. Here are a few I can remember without getting out my work computer to look at my notes. Some of these issues might not ‘belong’ to Windows, but they're all things which could come up for you on WSL2 that are unlikely or impossible to encounter elsewhere.

  - there's a showstopping memory leak in WSL2 that absolutely destroys your computer in terms of CPU and RAM usage, and makes your WSL machines completely unresponsive whenever you spin up a bunch of Docker containers
  - the PATH passthrough feature of WSL2 sometimes causes ‘.’ (the CWD) to get added to the user's PATH if your login shell is Fish (????)
  - `systemctl status` is broken with WSL for systemd 251 and newer
  - enabling systemd support (and using syschemd to run systemd-based distros without leveraging Microsoft's support for it) causes issues where launching WSL in an unprivileged instance of Windows Terminal means you can't access WSL in elevated Windows Terminal Windows and vice-versa
  - using hardware PGP tokens or other smartcards sucks ass, because forwarding your GPG agent to WSL guests is a huge pain (apparently WSLg runs its own `ssh-agent` process, and I don't know whether it has access to USB devices¸but I'd bet not)
  - WSLg has random and repeated crashes which spam you with popups for some distros sometimes, and it can only be resolved by shutting down ALL of your WSL VMs
  - WSLg's RDP crap gives you the wrong cursor (and one that's way too small)
  - WSLg's window management doesn't show mouse cursor changes correctly, so you have to *guess* when your cursor is in the right place to resize a window
  - resizing windows with Super+Click or Alt+Click doesn't work (either ‘natively’ to the WSL2 VM or via, e.g., AltSnap)
  - sizing and moving WSLg windows sometimes breaks completely. I think somewhere in the stack there's confusion about the positions of windows, which may be related to multimonitor setups
  - window maximization for WSLg apps doesn't work right when you have more than one monitor
  - OpenGL acceleration randomly decides it won't work for unknown periods of time with WSLg
  - basically any VPN completely fucking breaks networking inside WSL, so have fun using it at work
  - random crashes and freezes (not super frequent), so sometimes you come back to your machine after the weekend and none of your WSL sessions are usable and you can't open new ones
  - the `wsl.exe` has some weird encoding issue or doesn't respect the encoding set for the terminal emulator. Piping `wsl --help` into a pager doesn't work right (either natively on the system or from inside an instance via interop)
  - case sensitivity differences across filesystems sometimes breaks git repos, depending on which side of the OS divide they live on and where/how you cloned them
  - access to the Windows filesystem from WSL is so slow that it can take literally multiple seconds for a basic git prompt to draw
  - access to the Windows filesystem from WSL is so slow and so limited because of Windows behavior with file locking that sometimes you run into locking issues where running git commands from WSL is just broken
  - when your virtual disk, which is sparsely allocated, fills up, it takes up additional space on your machine forever, unless you intervene. Enjoy permanently losing dozens or hundreds of GBs of disk just for experimenting with Docker, until you shut your WSL VM down, locate the disk somewhere in $env:LOCALAPPDATA, and shrink it manually
  - for some absolutely unfathomable reason, WSL2's new built-in systemd support completely breaks TRAMP sudoedit in Emacs (just hangs, no log output that I could generate). the old, third-party syschemd hack for running systemd does not produce this mysterious issue. (this one was quite a puzzle)
  - unusable Linux binaries located on your Windows PATH from Docker GUIs like Rancher Desktop, Docker Desktop, or Portainer can cause your in-WSL Docker client to think it should use them for password management, making it impossible to use `docker login`

It's janky as all hell. I imagine users who report unproblematic experiences are simply not attempting to replicate a very substantial fraction of what an engineer might typically do on an actual Linux workstation.

And of course, you have to deal with the usual Windows bullshit. I have to manually kill `dwm.exe` every day because after being logged in for a day or two, window management causes a form of input lag that renders the mouse completely unusable if I don't.