Take the basename command in illumos, for example. This comes in two incarnations - /usr/bin/basename, and /usr/xpg4/bin/basename.
# /usr/xpg4/bin/basename -- /a/b/c.txt
Which is correct, and:
# /usr/bin/basename -- /a/b/c.txt
Wait, it gets worse:
# /usr/xpg4/bin/basename /a/b/c.txt .t.t
# /usr/bin/basename /a/b/c.txt .t.t
Perusal of the source code reveals the answer to the "--" handling - it's only caught in XPG4 mode. Which is plain stupid, there's no good reason to deliberately restrict correct behaviour to XPG4.
Then the somewhat bizarre handling with the ".t.t" suffix. So it turns out that the default basename command is doing pattern matching rather then the expected string matching. So the "." will match any character, rather than being interpreted literally. Given how commonly "." is used to separate the filename from its suffix, and the common usage of basename to strip off the suffix, this is a guarantee for failure and confusion. For example:
# /usr/bin/basename /a/b/cdtxt .txt
The fact that there's a difference here is actually documented in the man page, although not very well - it points you to expr(1) which doesn't tell you anything relevant.
So, does anybody rely on the buggy broken behaviour here?
It's worth noting that the ksh basename builtin and everybody else's basename implementation seems to do the right thing.
Fixing this would also get rid of a third of the lines of code and we could just ship 1 binary instead of 2.