For an implementation that supports URI/URLs (and opening ports from URLs),
I think it is better if the URL API is similar to filename URI.
For example, I think it makes sense to use the same API to extract
parts from a file: URL and from a filename object - in an implementation
supports working with URLs.
I think there are two issues here: parsing and the abstract model. There is no doubt that one needs multiple different parsers. For example (all strings are raw), "foo\bar\baz" represents a relative path with a single element to a Posix parser, but a three-part path to a Windows parser. The string "c://bar" will be interpreted differently by a Posix, a Windows, and a URI parser. For other obsolete native pathname interpretations (CLtL2 gives syntaxes for five PDP-10 operating systems plus VMS), other parsers would be required
Furthermore, the underlying abstract models don't overlap all that much:
Posix: Relative/absolute flag, sequence of file names.
Windows: Host, device, relative/absolute flag, sequence of file names.
CL: Host, device, relative/absolute flag, sequence of directory names, file name, file type/extension, version.
Generic URI: Scheme, rest-of-URI where:
rest-of-uri may be authority, host, port, sequence of file names, query, fragment where
authority may be username, password (deprecated), host and
query may be a sequence of key-value pairs.
So a full superset model requires the following abstract fields, some of which overlap: scheme, rest-of-URI, authority, username, password, host, device, port, relative/absolute flag, sequence of file names, sequence of directory names, file name, file type/extension, version, raw query, query a-list, fragment.
I believe it is fairly evident that this is far more complex than necessary for solving any particular problem. Unifying Posix and Windows filepath models is plausible: the Windows host and device fields are mutually exclusive and on Posix they are null. My library also allows unparsing a path object into a file: URI. But I just can't see going beyond that.