Article is from 2009. Plenty of prevalent short named tools have been released since then, causing exactly this sort of issues. Just thinking about it, "node" and "npm" come to mind.
POTENTIALLY. This (for me, anyway), is a solution in search of a problem. Been using some sort of *nix since the early 90's, writing scripts and commands and aliases and functions the whole time - this has never once happened to me.
It obviously _can_, and PROBABLY has, to some. But it's more a "can" than "will". Maybe I just name my homebrew stuff in a way that's unlikely to collide, dunno.
I put ~/bin/ at the start of my path as well. It works very well for me, but I also have to admit that I've never experienced a name collision from doing this as far as I'm aware.
I'm not on the comma train here because it makes the name ugly and confusing, and doesn't solve any problem that I have. But it is a clever hack for those who do have this problem.
What is "system path"? Every tool inherits the caller's path. I don't think this could be a problem unless a tool talked directly to systemd to execute itself.
in the context of "some tool that expects $0 in the system path..." - i do not understand either.
if a tool looks up a command name "x" given to it, it just takes $PATH and goes through it. the same $PATH as in your shell when you call "x" directly.
thinking more about it, you must thought something like putting "@daily mycommand ..." in crontab, then being annoyed by it not finding your command.
then the problem is not that some tools expecting a "system path", but that some tools being defiant and overrides inherited path on their own accord. which is totally unneccessary: environment is called environment because it is prepared for you (the given program) to run in.
The danger is also mitigated because I only modify my own user's shell rc file. Any daemons running as root or their own user are unaffected.