Thanks hn for doing what you do! I'm so glad to see this here.
A few months back I noticed '[' under /bin on my mac. I tried googling to understand what it was, but my google-fu came up short. It felt like one of those ungoogleable things. This link is an excellent starting point for me.
They look similar, but to your shell they are different: [ is the name of an executable, ( is a syntax symbol of bash. The man page for the syntax is the man page of bash.
What's not so funny is that /bin/[ has no way of enforcing this syntax rule, or any other. Just like sed can't enforce any syntax rules on its regular expressions. This is why the shell is still a crock of shit for scripting even with "set -e" on.
The invoked binary has no way of aborting script execution. All it can do is barf out on stderr and return an error code, which the shell interprets as false and `if [ "x" = "x"` (without ]) goes into the else branch.
I like the cut of your jib. Finally a breath of fresh air from a sane person amongst all the crazy people making fanatically apologetic excuses and heaping evangelical praise on toxic burning dumpster fires.
It could have still been implemented like that in the filesystem, if the binary read the name it was executed under and modified its behavior based on that. As an extreme case, on a stock Alpine Linux system, both test and [ - along with most other core system programs - are all symlinks to a single busybox binary that reads argv[0] and acts like whatever program it's been called as. I'm actually somewhat surprised that GNU didn't do that in this case; I, too, would have expected test and [ to be some manner of link to the same program, either with identical behavior or using invocation name to decide how to behave.
A few months back I noticed '[' under /bin on my mac. I tried googling to understand what it was, but my google-fu came up short. It felt like one of those ungoogleable things. This link is an excellent starting point for me.