This is already how busybox works. These examples are taking it to a more extreme level but it's not _that_ crazy.

It may be a bit uncommon, but it's not at all new. For example, on a Linux system I have, there are several files in /usr/bin that use hard links to refer to the same file (inode) by different names:

bunzip2 / bzcat / bzip2

gunzip / uncompress

unzip / zipinfo

pigz / unpigz

pkg-config / x86_64-pc-linux-gnu-pkg-config

perlbug / perlthanks

Use ls -li to show the inode number for each file or directory. For example:

    $ ls -li /usr/bin/{bzip2,bunzip2,bzcat}
    23069197 -rwxr-xr-x 3 root root 39144 Sep  5  2019 /usr/bin/bunzip2
    23069197 -rwxr-xr-x 3 root root 39144 Sep  5  2019 /usr/bin/bzcat
    23069197 -rwxr-xr-x 3 root root 39144 Sep  5  2019 /usr/bin/bzip2

If the rename changes the entire behavior (see busybox comment) it makes sense. But defining multiple arguments? Now the author had to use -- in the file name where using space would do (and the OS splits it for you)

And good luck trying to run the same programs with different arguments. You'll have to take turns renaming the file, or create hardlinks just for ephemeral arguments.

It can be useful but there's time and place to do it.

This strikes me more as a matter of taste, i.e. more art than something which can be provably wrong, or correct for that matter. The concerns you outlined might be concerns the author doesn't have to worry about for whatever reason -- if this fits neatly and seamlessly into their existing workflows then that's great, and I for one appreciate learning about other peoples' approaches like this even if they don't immediately work for me

IMV it's a clever trick, and like you my instinct is that if I attempted to integrate this into my own workflows, I would endure some sort of hardship down the line but it's not immediately obvious when or how. Or maybe for certain things it would be fine and less painful than other options, like other similarly clever tricks I felt uneasy about at first

I too was perplexed, but the main use case seems to be when you want to share a particular configuration or need to be sure that you always use the same set of flags:

> Flags are ephemeral – you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability. Filenames solve both: the program describes itself, requires zero setup, and any configuration can be shared by simply renaming the file.

[Emphasis added] Although I find a script that wraps the command and calls it more versatile, there might be some value in this idea for some very simple cases, like example #4.

I guess you could rename it to foo--bar--help.exe to get the help. An awkward workflow indeed