Protocol specifiers are ambiguous?

If you use Unix file paths and delimiters, it seems like it would be really easy to make things ambiguous.

First off, I don't see a "file" protocol type, is this the the unix protocol type listed in protocols.csv?

If so, what happens if I make a file path /home/icefox/tcp/127.0.0.1/foo and try to represent it as a multiaddr path?

/unix/home/icefox/tcp/127.0.0.1/foo

Okay, that's a little artificial, and you could specify that you can disambiguate from context; a unix protocol address cannot contain a tcp protocol subaddress. Though that seems to defeat the purpose; things stop being self-describing and become context-dependent. (And on Plan9 you certainly can do TCP via the filesystem.)

Okay, what about a more concrete example using already defined protocols:

/wss/example.com/http/example.com

Is this accessing the websockets endpoint wss://example.com/http/example.com, or is it trying to nest the HTTP protocol inside the websockets endpoint wss://example.com/ ?

Start with protocols.csv and the multiaddr examples in the issue, especially the unix path and nested wss/http forms. Determine how protocol boundaries and filesystem paths are specified and parsed. Done means the specification resolves these ambiguities without relying on unstated context.