AmigaOS actually did use : as a volume marker and / as a path separator below the volume level. "Volumes" on AmigaOS were actually more like generally-usable filesystem namespaces; the feature covered not just "hardware" volumes like DF0: or DH0: (equivalent to A: or C: in MS-DOS) but "logical" ones as well, which worked a bit like chroots in a modern OS.

You could even use a physical medium label as a volume, and the OS would interactively request (via a dialog box) that the user insert the requested media into any physical drive, so that the system could interact with it; the whole notion of "is this media/physical resource available right now" was something that the OS would abstract away for you! (I think the closest thing to this currently might be RedoxOS's idea of using URLs as generally-applicable path indicators, since URLs too have a base-level resource indicator (the "host" part) and a subpath.)

Program options were dealt with by requiring paths to be entered as strings in quotes in the general case, and disambiguating them only as a last resort. There was no option prefix at all, so you would enter, e.g. `list files` as the equivalent to `ls -l`, and `list "files"` to list only something named "files".

And for this reason you still can't name your file ":" in Finder today.

You can name it "/", though. If you look at it in the terminal, it will be named ":".

And amusingly, if you create a file named ":" from the Terminal, it'll show up as "/" in Finder :)

$PATH breaks under most implementations even under Linux or BSD with that. It shouldn't; though.

That's because the only special characters in file paths in Unix are / and NUL. You can't pass NUL through environment variables, both because of the C API for manipulating environment variables and how the environment is passed to the host program by the kernel--environment variables are delimited by NUL, as are argv arguments, and the argv and environ lists are delimited by a double NUL. So the shell had to pick some random delimiter, and whatever it chose would conflict with existing path semantics. Fortunately, it only effects the semantics of PATH--the colon is irrelevant everywhere else, and PATH isn't strictly necessary for anything, not even in the shell.

There's no easy way to fix that. I suppose PATH could instead be split into PATH_1, PATH_2, PATH_3, etc, with a single path per environment variable. I've used such a solution to emulate arrays for both internal and environment variables. But that ship sailed a long time ago: the semantics of PATH are built into the shell, libc (because libc's execvp, etc are what traverse $PATH looking for an executable, not the kernel), countless other programs, not to mention the POSIX standard itself.

Fish shell gets around this by using a list for it

Yessir. (fish core dev here ;)

Not all “Classic Macs”. MFS, the file system used on the original Macintosh, didn’t support subdirectories (the folders that the Finder showed were illusions created by the Finder) (https://en.wikipedia.org/wiki/Macintosh_File_System), so it didn’t have path separators.

But it probably used : to separate the volume name from the file name.

Checked the phone book (https://en.wikipedia.org/wiki/Inside_Macintosh). As I remembered, all APIs used a volume reference number and a file name.

However, it also says (emphasis added):

”When accessing a closed file on a volume, you must identify the volume by the method given above, and identify the file by its name in the fileName parameter. FileName can contain either the file name alone or the file name prefixed by a volume name.

(note)

Although fileName can include both the volume name and the file name, applications shouldn’t encourage users to prefix a file name with a volume name.”

So ,that, sort-of, but not fully, confirms your statement.

I don’t remember ever using a path like that, and wonder what the OS did with those volume names: ignore them, and use the volume reference number to determine the volume to use, allow them to override the volume reference number, or check them against the name of the volume with the reference number?

I remember in a conversation with a school friend taking about the superiority of Macs and how Windows had the reserved forward slash, and he replied that Macs had reserved the colon. I was shocked, I had never come across it before and immediately tried to or colons in my file names.

For fun factor, one can peek Common Lisp's support around make-pathname - http://clhs.lisp.se/Body/f_mk_pn.htm#make-pathname - just scroll down, and you'll UNIX, LISPM and VAX formats:

Some OS I used in the 80's used MFD0 and MFD1 for drive assignments. It stood for Main File Directory.

AmigsDOS was an odd bird that used things like df0: (drive, floppy, 0) and dh1: (drive, hard, 1.)

AmigaOS would have both a name for the physical device like df0: and dh1: above but also a label or volume name which could be work: or something and those would mostly be interchangeable from the shell to refer either to "any volume named foo:" or "whatever disk is in drive0 right now".

iirc: The Mac colon convention wasn't really baked in at the API level. It was used in displaying paths but not really in manipulating them.

Correct. While it was possible to use file paths, it was highly encouraged to use file system references and store alias structures.

This enabled Mac-like behavior like letting you rename and move around files (even open ones) without apps losing track of them, supporting network share auto-mounting, etc.

Nope, most Mac filesystem APIs would interpret : in a name as a path component. There was even an equivalent to the current working directory. No system-supported :: traversal syntax though.