Ultimately it's essentially an arbitrary choice, but the reasonable set of characters would exclude letters and numbers (too widely used for filenames already), be already available in the character sets of the time, and not too awkward to type nor look at. That means it'll be one of the special and non-paired (like parentheses) characters, and beyond that any single one would do. Beyond that, any one is as good as the others.

We could've just as easily ended up in a world where options are introduced with \ and path separators are commas, or any number of other combinations. It's a little funny to think that the TOPS-10 developers probably spent less than a day in total deciding on the character, far less than the time spent by everyone else since then thinking about why they did it that way.

I doubt it was a day. I'd be surprised if it was more than a minute or two.

TOPS-10 subdirectory separators were commas, but the path was enclosed in [] so it was always clear which part was a path and which part was something else.

UNIX and DOS/Windows made a big mistake by removing the enclosing characters, and TOPS-10 was a 6.3 file system that never used them to their full extent.

The (back) slashes and switches weren't the biggest problem. Spaces in file paths were - and sometimes still are - hard to deal with.

A standard pair of enclosing characters would have eliminated a lot of unnecessary and unreliable escape character logic, and would also have allowed almost all other characters to be used without problems.

> A standard pair of enclosing characters would have eliminated a lot of unnecessary and unreliable escape character logic

Windows allows you to enclose paths in double quotes, which deals with the space problem.

Off the top of my head, I don't recall if Linux has the same behaviour?