Then there is no WSL 2 handling in your editor. VSCode remote extension works in the same way for either WSL 2, or a full-fledged Linux VM, or even a remote Linux server.

As someone who run a Linux VM side by side all times, I really don't get WSL 2.

It's the same as saying: " As a person who runs containers all the time, I really don't get Docker".

The point is VS Code handles my code hosted in WSL 2 out of the box. I don't care that I could use a VM or a remote server instead.

I just suggested that the parent commenter waits for is IDE to implement a similar integration...

VSCode made some unique design choices which enable them to support connecting to any Linux server, VM or not. In contrast, these design choices may not be possible for other IDEs. So, because WSL 2 is, effectively, a Linux VM, supporting it in editor is harder than supporting WSL 1.

As for "I really don't get" part, I wanted to say that WSL 2 sounds like a regression to me, WSL 1 makes it possible to achieve something (namely, local-ish cross-"os" net/process/file-system integration) that is entirely impossible otherwise, while WSL 2 is a nice packaged-up solution but functionally does not do more than people already get (Hyper-V).

The software engineer in me agrees with you, WSL 1 was architecturally more ambitious than version 2.

As a user, I couldn't care less. I just hope Microsoft manages to create a good ecosystem around WSL.

Then you could as well run your stuff in a regular docker container, WSL becomes redundant.