Windows seems to have a certain hard limit on file path characters (a max of 160) which they seem to have recently removed [0] - So while my point is technically moot it's not enabled by default.
As for soft links, a lot of linux tools create soft links (ln -s from to) and generally that fails on NTFS (I tried installing a bunch of npm modules and all had this specific issue)[1].
It's a max of 260, and it's a Win32 subsystem limitation, not the limitation of NT OS or NTFS file system - and even in Win32 there are escape hatches for it, it's just that you need to know of them and use them explicitly to get such support.
With respect to symlinks - NTFS supports them, but there are subtle semantic differences with POSIX. WSL does actually support symlinks (i.e. you can do ln -s), it's various other behavior around them that breaks, like trying to untar a file that contains symlinks.
The team said that they're working on a custom implementation of symlinks that would provide proper behavior (but wouldn't be seen as a symlink from Win32).
I think the problem here is that Linux NTFS drivers are all a pile of reverse-engineered hacks, so obscure features are overlooked or not fully implemented.
Now, Microsoft should be in a position to put something better into their WSL, but that might entail the risk that someone else will hack that implementation and provide good drivers for everyone, something they clearly don't want (or they would have provided open specs for NTFS support by now).
As for soft links, a lot of linux tools create soft links (ln -s from to) and generally that fails on NTFS (I tried installing a bunch of npm modules and all had this specific issue)[1].
[0] - https://mspoweruser.com/ntfs-260-character-windows-10/
[1] - https://stackoverflow.com/questions/8232778/nodejs-npm-insta...