I think you always can. In the past you may lose some features / have some bugs. For recent kernel versions (>= 6.6) the only patches WSL kernels have is dxgkrnl + some hacky fixes for clock sync. Others are all in upstream already. So you'll just lose WSLg / CUDA passthrough and nothing else now.
Of course, there might be some regressions. They are usually only fixed (upstream) after WSL kernel gets upgraded and it starts to repro in WSL.
Their kernel modifications and patches are public, and some of them have been upstreamed long ago. You'll need to compile your own to get the benefit, but I don't see why you wouldn't be able to use your kernel of choice.
Of course, if you want the native integration WSL offers, you'll need to upgrade the Linux driver/daemon side to support whatever kernel you prefer to run if it's not supported already. Microsoft only supports a few specific kernels, but the code is out there for the Linux side so you can port the code to any OS, really.
With some work, this could even open up possibilities like running *BSD as a WSL backend.
A version that tracks the underlying distro better, or even closer to mainline. Current WSL2 kernel is 6.6, kernel is 6.12 or 6.15. Debian Trixie will be 6.12.
strace shows that the sleep program uses clock_nanosleep, which is theoretically "passive." However, if the host suspends and then wakes up after the sleep period should have ended, it continues as if it were "active."
