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

That's more a case of providing the distinct "APIs" ( bzip2 , gunzip etc) to userland / scripts, while the implementation for all is just one binary; than it being "Configuration via name..."

Somewhat similar to how busybox does its thing.

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

AIUI, on Windows, pip (via the vendored `distlib`) also makes stub executables that work this way to implement the "entry points" defined in installed wheels. See: https://github.com/pypa/distlib/blob/master/PC/ReadMe.txt

I'd say "kind of", because it's ridiculous on the surface but could be a handy trick. If only to be aware that an executable gets told its own name.

I have used that in a project of my own[0] for convenience (avoid duplicated code), but it is uncommon, yes.

I truly think it should be avoided in general, especially when what you actually want (in OP’s article) is a config file.

[0] https://github.com/Frizlab/frizlabs-conf/blob/44030f4123e683... (w/ that, also see the aliases in the folder of the script)