The differences between distros in fact break scripts that need to refer to these tools by their absolute paths, which includes anything called from cron where the value of PATH can be anything and systemd services, or any script where use of relative paths is risky for security reasons, exactly to avoid malware in /home/user/.local/bin, for example.

So for all sense and purposes, the current state is broken. Your suggestion that will foil script kiddies, while in theory plausible and potentially having occurred some times, is ridiculous and is an example of security through pseudo-obscurity. If your security relies on your script kiddie not knowing where update-alternatives is, your system lacks any security.

On the other hand, the fix will temporarily make things more broken, as now people referring to tools with absolute path and using Fedora (or Arch) will not know where the tools are supposed to be, even for tools where the path was previously consistent across distros and will hardcode /usr/bin/fsck, which in Debian would be in /usr/sbin/fsck (and if someone hasn't yet performed their /usr merge, even /sbin/fsck). Which means Arch and Fedora will be compatible, but not Debian, and Debian will be forced to also merge them eventually.

I did mention phones, because Nautilus is usable devices like tablets as it has touch-friendly navigation, with an adaptive interface that hides the sidebar on small screens like a phone. They've recently almost fixed the constant issue where the window would become too big to fit on a screen by adding a lot of ellipses, though some other parts of GNOME (the file picker, for example), would become too wide to fit any screen by simply navigating into a directory whose name is too long.

As an avid user of orthodox dual-pane file managers (far2l, Midnight Commander, Double Commander, and Krusader when using KDE), I am not sure of it. Allow us to have file managers that are best suited for the task at hand and best fulfilling the preferences and needs of the user.

Some tasks --- editing files, watching video files, managing files on a phone screen, rarely even some file organisation within subdirectories --- are best accomplished with a single directory view, without a second pane taking up your real estate. Opening a second window to take the job of a second pane is a minor hassle if suddenly required, and can be much more flexible --- sometimes you might need three of four, or to close and open more of them as needed. Some single-pane file managers even offer opening a second pane with F3 (Dolphin and pcmanfm, for example), and this is valuable, but it is neither that much significant improvement over opening a second window, nor does it offer the power of a primarily dual-pane manager like the ones I mentioned.

It might be prudent to have such mode in all file managers, but even when everything in my life is dual-pane I seldom use it, because every operation in a truly dual-pane manager is aimed at the presence of exactly two panes. Copy, move, symlink are aimed at the opposite pane (as opposed to drag & drop with windows, or with an F3 split), macro actions can be created that reference the active and inactive pane, or left and right pane (useful for making diffs), comparison and directory synchronisation features may be also provided. That's the true value of the design, so simply splitting the view does little to give you that.

On the other hand, single views --- splitable or not --- are great for what they do. Sometimes you just need smaller window, sometimes you just need independent views where a dual pane wouldn't be the best fit, sometimes you even more than two. I've even been in a situation where I needed to run multiple instances of a certain dual-pane FM (because of the macros I had in them, or the ability to use them over SSH), and all operated in a single directory, the second pane sitting there eating screen space for no reason.

Perhaps you forgot to check that argumentum ad populatum is still a logical fallacy in 2021.

My company makes up some of those 80% powered by PHP, I make my salary supporting PHP web sites and coding PHP code myself, I even like some of the overall language, and PHP happens to be the first language in which I coded any non-toy programs.

Yet it is still pretty much THE shitty language. A primer on how you DO NOT create a programming language, from security hell to just absurd language features that trip you on every step. You wouldn't need to look past what kind of absolute crap has to be fixed with breaking changes in each major release that's came out in recent years. For example, the recently released PHP 8 fixes the absolute insanity of PHP comparison operators: https://www.php.net/manual/en/...

Before this change (and since PHP 8 compatibility is not here yet in popular libraries, you can say it is still the case), you would struggle with BASIC things like checking for an empty string:
if ($s == '') // WRONG, if someone passes 0, it will evaluate to true, yet result in non-empty string
if ($s === '') // WRONG, if someone passes false or null, it will evaluate to false yet result in empty string
if (!$s) // WRONG, if someone passes "0" or 0, it will evaluate to true yet result in non-empty string
if ((string) $s == '') // CORRECT (though it could probably result in an error in a number of cases, good by me)

That's what we're fixing in 2020/2021. In the decades, it's a language that brought absolute wonders like magic quotes, which would any mangle any input string with C-style escapes, in the false belief that this protected you from SQL injections. SQL injections resulted from this, yet it also brought the joy of web sites in which passwords containing " or ' or \ would not work, because they would be “escaped”, and your password would differ from what you actually typed.

Mind you, when that was happening, the default MySQL library didn't even contain the ability to pass parameters to queries. And when parameters were added with MySQLi, it happened with an over-engineered complicated system that totally discourages you from using it. Now, to add query parameters, you individually bind each of your query parameters to a variable, which it now references, and can set to whatever value you want. That's powerful, but complicates code for passing simple parameters, thus discouraging people from doing so, and still writing vulnerable code. To this day.

And if you're going to say that these are things of the distant past, think again. MySQL has been fixed, but shell commands still haven't been - on POSIX, there's no way to safely run a command composed out of execl() arguments, it always goes through the shell. Not only that invoked shell vulnerabilities like shellshock in the past, it means you have to carefully escape every argument, individually, with escapeshellarg(), which breaks badly on different locales, and is still prone to the programmer forgetting an argument, as with SQL queries without parameters.

To make it all harder, changes brought to fix these gaping holes of the language have been done in ways that would be disruptive to existing code, and done so often, all the while support for earlier releases have been made short. In other words, we break your code, and break it often. When magic quotes was removed, so was the ability to turn it off, making attempts to do so a fatal error, and complicating the upgrade between two versions that both lack the stupid thing.

Or, along with wanted fixes to the comparison operators, PHP 8 decided to make the signatures of methods during inheritance mandatory. Now, that technically makes sense, but in a language where you can dynamically take and pass the arguments, the new PHP version rejects code that does so with a fatal error, thereby breaking scripts that are correct. It's probably still the correct change, but add that to the fixes for outstanding issues that are also breaking, you're looking at a never-ending stream of breaking changes. And all code needs to be updated within a couple of years, because support for the PHP versions without the breakage is dropped fast. It's better than the Python 2 to 3 transition, which was one big pain in the ass, but at least that one you could put behind you. The PHP breakage is an ongoing process, and I have no confirmation it is done yet.

And let's not forget that the majority of GNU/Linux malware happens on PHP installations. And while the bad security of PHP scripts is not a fault of the language (except when it is, see above), and while the tendency of PHP users to download outdated unauthorized copies of commercial software even less so, PHP has become nesting grounds for malware. That's on top of the database leaks in which it has been complicit.