A single command doing two completely different things arbitrarily depending on file matches isn't an "edge case".

But this very common for many tools:

  touch -- -l
  ls *

However, if you run both commands consistently, nothing untoward occurs:

  touch -- -l
  ls -- *

The fact that you have to use a double-hyphen flag to create a file with a name starting with a hyphen is a strong indication that this situation is an edge case.

And git handles the edge case the same way. That was my point.

  rm master
  git checkout -- master
  git checkout a1b1
  git checkout master -- master

all works as expected

Not quite. I believe the point is that it's not an edge case, since "master" isn't a particularly unusual name, not in the Unix tradition, nor, AFAIK, on any other OS.

You'll note that, for example, your "rm" didn't require a double-hyphen.

The OC's point (and maybe the GP's point [1]), ultimately, is about git command syntax ambiguity. With traditional Unix commands, there's not much ambiguity. At worst, there's merely no obvious way to pass an argument that's a filename starting with a hyphen. The question "what does 'ls -l' do?" would not plausibly have an answer of "output '-l' if a directory entry with that name exists" in addition to "output a long listing of all directory entries".

[1] Does git actually behave differently based on the existence of a directory entry named "master" or does it merely require extra effort to work with such an entry, which would actually be directly analagous to filenames beginning with a hyphen?

That's bad too.