Yeah, there are some issues with some corporate VPNs and WSL2 right now (disclosure: I work at Microsoft but not on WSL2 but I’ve been in touch with that team regarding some of the issues) that are actively being worked on.
I think that’s a bit different than this, though it’s possibly related. As you said, the situation there is traffic is blocked.
WSL and WSL2 are fundamentally different in how they work. In fact, the poor I/O performance (caused in part by Windows Defender) in WSL is part of what led to the Hyper-V based approach to begin with.
My guess is that something might need to change either in the way VPNs use the firewall rules in Windows when passing on to WSL2 or in WSL2 to make for more granular control over how that stuff is passed on - to address the Mullvad. Because as it stands now, the way Mullvad performs under WSL2 seems to be by design (by WSL2 design, if not Mullvad’s design).
Obviously, many users who enable a VPN in Windows will want that connection to persist when they use WSL2 — but I can also think of plenty of scenarios where that might not be the case, which I imagine makes coming up with a solution more difficult.
I will say, the WSL2 team is incredibly responsive to feedback. You can file issues on GitHub and the team is very active on Twitter. If this is something that can be fixed on the WSL2 side, I feel confident the team will work to do it.