> A fix is to make path normalization file system dependent.
First, there's a technical problem, that normalization is currently done when the FileSystem is unknown, under Path's constructor. But, even so, I'm not sure that will solve it.
By this you mean that a local path that contains backslashes will have them escaped by Path's constructor. So that "[bar,baz]" will be parsed as "/[bar,baz]", while an HDFS path like "[bar,baz]" will be parsed as "[bar,baz]", so that the '[' is unavailable for globbing. But then applications which run on both unix and Windows and using both the local fs and HDFS will have to pass in different kinds of path strings, no?
Not all paths come from a FileSystem implementation, some come from environment variables, config files, constant strings in user code, etc. Thus we must be able to handle Windows file names passed to the Path constructor that have not undergone special escaping, e.g., C:\foo\bar should be parsed as c:/foo/bar. We've tried other approaches and they've not worked well.
This is a hard problem to handle well:
Perhaps we need to expect some Path-related things to be broken on Windows, but make those be rarely used things. Windows paths that contains '[' or ']' simply might not work correctly when passed to listPaths unless the user is careful to insert escapes: we will not attempt to insert such escapes automatically. We would only translate '\' to '/' when running on Windows, and only then when it's not immediately followed by another backslash. This will mean that a directory whose name starts with a glob character will not work correctly on Windows unless the developer manually inserts appropriate escapes, but that globs will work correctly on Windows. My assumption is that directories beginning with glob characters are much more rare than uses of glob characters for globbing. Could that work?