WSL2 has fewer "magic unknowns". WSL1 used the NT Kernel emulating the Linux kernel so there was a lot of (seeming) magic in that interop, because it relied on low level NT details that don't look like "normal" Windows to Windows.
The files, for instance, were stored in NTFS but with Linux metadata in alternate data streams. Akin to what macOS used to call Resource Forks, except alternate data streams are far more rare in Windows and most native Windows apps trample over them. Microsoft didn't advertise where to find those files specifically because they didn't want people using Windows apps on those files and breaking Linux metadata. Instead, Microsoft heavily encouraged using /mnt/{drive letter}/normal/windows/path (like /mnt/c/users/me/Documents) and normal Windows paths and keeping files you worked on in both environments in the Windows plain old NTFS without alternate data stream weirdness side (because those /mnt drives didn't use the Linux metadata alternate data streams).
Eventually, Microsoft added a Plan9-based file server to WSL1 serving on the \\wsl$ system path for browsing those files and some smarts around it. (Launching a Windows EXE from a WSL terminal would convert the Linux path to the \\wsl$ path for instance.)
WSL2, on the other hand, is an extremely lightweight (Hyper-V based) VM, uses a real Linux kernel, and generally uses VM tech. Files are stored in a standard VHD, which can be explored with plenty of VM tools (including Windows File Explorer). They are still accessible in File Explorer through the \\wsl$ service. (Though in that case Windows can mount them using standard VHD mounting. The direction of the Plan9-based file server winds up reversed from WSL1 in that it is used instead by the VM to access host machine files through the VM barrier.)
As for F#, F# itself is an open source project with possibly a lot more of a "community project" mentality than it is an "official" Microsoft release. I don't know if that changes your opinion, but it is one of the projects where Microsoft has best embraced open source. (Including some of the potential downsides of open source, like needing Github Issues filed on broken documentation or it will go unnoticed/unfixed.)
The files, for instance, were stored in NTFS but with Linux metadata in alternate data streams. Akin to what macOS used to call Resource Forks, except alternate data streams are far more rare in Windows and most native Windows apps trample over them. Microsoft didn't advertise where to find those files specifically because they didn't want people using Windows apps on those files and breaking Linux metadata. Instead, Microsoft heavily encouraged using /mnt/{drive letter}/normal/windows/path (like /mnt/c/users/me/Documents) and normal Windows paths and keeping files you worked on in both environments in the Windows plain old NTFS without alternate data stream weirdness side (because those /mnt drives didn't use the Linux metadata alternate data streams).
Eventually, Microsoft added a Plan9-based file server to WSL1 serving on the \\wsl$ system path for browsing those files and some smarts around it. (Launching a Windows EXE from a WSL terminal would convert the Linux path to the \\wsl$ path for instance.)
WSL2, on the other hand, is an extremely lightweight (Hyper-V based) VM, uses a real Linux kernel, and generally uses VM tech. Files are stored in a standard VHD, which can be explored with plenty of VM tools (including Windows File Explorer). They are still accessible in File Explorer through the \\wsl$ service. (Though in that case Windows can mount them using standard VHD mounting. The direction of the Plan9-based file server winds up reversed from WSL1 in that it is used instead by the VM to access host machine files through the VM barrier.)
As for F#, F# itself is an open source project with possibly a lot more of a "community project" mentality than it is an "official" Microsoft release. I don't know if that changes your opinion, but it is one of the projects where Microsoft has best embraced open source. (Including some of the potential downsides of open source, like needing Github Issues filed on broken documentation or it will go unnoticed/unfixed.)