path.windowsParsePath and windows.getUnprefixedPathType discrepancies #25702
Description
Zig Version
0.16.0-dev.747+493ad58ff
Steps to Reproduce and Observed Behavior
See #25681 (review) for context. The short of it is that std.fs.path.windowsParsePath and std.os.windows.getUnprefixedPathType perform roughly the same function, but disagree on the types of certain paths.
One example is mixed path separators as the first two characters of a UNC path, like so:
/\server\share/
\/server/share/
std.os.windows.getUnprefixedPathType sees these as UNC paths, but std.fs.path.windowsParsePath does not.
The windowsParsePath behavior has implications for std.fs.path.resolveWindows, where something like:
/\server\share/../relative
will resolve differently depending on whether or not it's considered a UNC path (\\server\share\relative) or not (server\relative)
Side note: there's also the concept of namespace prefixed paths that std.fs.path doesn't really deal with but std.os.windows does (e.g. NT-prefixed \??\, verbatim \\?\, etc). I'll likely file a separate issue for that.
Expected Behavior
std.fs.path.windowsParsePath and std.os.windows.getUnprefixedPathType to agree about path types more generally.
std.os.windows.getUnprefixedPathType is intended to follow the lead of RtlDetermineDosPathNameType_U, which sees /\server\share/ and friends as UNC paths, so I think that's the behavior that windowsParsePath should have as well.