Windows symlinks (mklink) on drvfs pointing to \\wsl$\... should resolve in WSL

Version

Microsoft Windows [Version 10.0.22000.613]

WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version

5.10.102.1-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

On Windows:

cd C:\Users\blami
mklink /d src \\wsl$\Ubuntu\home\blami\src

In WSL2:

cd /mnt/c/Users/blami
ls src

Expected Behavior

src on drvfs (9p) resolves correctly as a symlink that points to /home/blami/src in same (or another) distribution. If I do not have rights to access that directory on Linux side, then its fine. Even limiting scope to just same distribution would be fine.

TL;DR explanation: I do not want to have different set of profiles for Windows and WSL (ssh keys, gpg keys, various configs for things like editor, scripts, etc.) so I usually change my home directory in WSL to /mnt/c/Users/blami. That slows down some tools that read configs from home (on WSL) but its acceptable price for not having syncing chaos between two environments. While I learned to live with regression making symlinks created on WSL side no longer work on Windows side, I cannot use NTFS drive for programming projects as it is too slow and Microsoft is not doing much with drvfs/9p perfomance since WSL2 came out. So to workaround I want to put my programming projects to src/ on WSL VHD and symlink that directory to my %USERPROFILE% so that all my projects are accessible from same place in both WSL and Windows without 9p performance cost on WSL side (I expect accessing them from Windows will be hit which is better as I usually only look at them/edit them on Windows, but never build). This is not possible because only Windows side understands \\wsl$\... symlinks.

Actual Behavior

ls: cannot read symbolic link 'src': Input/output error

Diagnostic Logs

No response

microsoft / WSL