I played around for some reproduction attempts. (on windows 10 pro 1809)
Here are some more information, maybe that helps also:
With webdav it turns out that windows is complaining at the moment when the path (only folders) length is 240. A folder structure with 240 digits will not allow to create any files, or copy of anything to a local place. (you have to delete 2 digits to copy the path to a local drive)
F:\kjsafnlakjsdflaksjfhlaskjdfhlaksjdfhlakjsdf\02389470239847012984370182934709128347\ödslkjafhlkajsdfhlkjadsfhlkjasdhflkajdsh\98302470198423701298470192834701923847\ldksjfhdksjfhlakjsdfhlasdkjfhlaskdjhflaskdjfhlaskjdfhlaksdf\ldkfölsa11111
On Dokany, it’s a similar, but not “consistent” behavior. It allows to create 248 paths in the vault, but if you want to copy something out of the vault (or into it), you have to go down to 224 digits. I also noticed, that if you want to copy a (too long) path out of the vault a part of the folders is copied to a local storage when the error message appears. (On Webdav nothing is copied if the path is too long).
But in any case I got a message that the path is too long. I did not get the message that a file would not exist
And If I want to create that long path names at a local storage area, I receive the same message and experience the same behavior as on a webdav vault. So In my case I was not able to even create a file with that long path on my local drive, or directly in a vault.
I could imagine that there be a compatibility issue if you create and feed your vault on environments that allow file paths with more than 240 digits, and then try to open the vault on a windows machine that does not allow such long path names.
Anyway, I wasn’t gonna be able to create files in long paths on the “local environment”, or directly in the vault without windows warning me that the path is too long.
So for me it feels like a “windows vs linux vs mac” thing.