The Debian situation is kind of weird with their tooling maintainers opposing the merge and the distro maintainers trying to push the merge through. In true Debian style it started as a technical issue, but now it's a political one. I don't think we'll see the merge actually making it for all packages without issues for a while.
That said, there is a clear trend in distros to move to merge these directories and I don't see why not. There are some niche use cases for different partitions containing different binaries and such, but like all niche use cases you're going to need to configure those yourself.
The opposition's argument seems to revolve around "we always did it this way so we can't do it any other way", really. This is the stuff that led us to a world where the most popular distro now packages the standard browser in a Snap package.
> The opposition's argument seems to revolve around "we always did it this way so we can't do it any other way", really.
My understanding is that the technical objection is that Debian packaging tooling isn't up to snuff to deal with a merged /usr. There are various corner cases and technical debt that cause headaches.
And that the people promoting /usr are not doing the necessary work to get Debian to that point. That is they are not submitting useful patches.
So some patches and fixes have been submitted to correct the issue, but those have been blocked because they are not technically sufficient or high enough quality (??? not sure).
Something like that. I don't follow the drama. But that is my understanding last time I checked.
....
And then there is the issue of dealing with the conversion to merged /usr in existing systems.
For distributions like Fedora this is solved by putting the upgrade logic into the installer; anaconda. This way major changes, like init systems or merged /usr, is handled when you upgrade from one version to another.
Debian doesn't work that way. They want to be able to handle upgrades 100% through the package management system and debconf.
Debconf is essentially "install wizards" to allow people to choose configurations when packages are installed/upgraded and doesn't have equivalent functionality in the RPM world. One of the very few meaningful technical differences between deb and rpm.
Beyond all that there was past goes at attempting merged /usr, which depended on user selected preferences.
So this means that there are live systems that are a mixture of possible "/usr states". So those use cases need to be handled as well.
Which means that...
Yet again Debian politics has caused the creation of a vast amount of technical debt that must be overcome for it to move forward. Technical hurdles that are not experienced by other distributions. And because of that currently existing Debian installs can be in a sort of limbo half way between combined /usr and not, which is pretty much the worst possible outcome from a technical point of view. Ideally the change should be atomic in nature.
This is not terrible as many people place politics as a higher priority than technical excellence. So this state of affairs is actually desirable for many. Which is fine. Putting in extra work to help ensure that everybody is happy as possible with the outcome is not the worst possible thing you can do with your life.
For Debian it's more than just that the code isn't ready, the debconf guys and the design guys disagree and both consider the merge something that can decide about within the project. And to a certain extend, they're both right, which makes it even worse.
My understanding is that the Debian people tried to get a merged /usr going without consulting the packaging people. The packaging people not only ran into technical issues, they also disagreed with the decision itself. Eventually some patches were made to make it sort of work, but also with a warning that merged /usr is basically unsupported and can lead to breakage (which is technically correct). Then someone else tried to remove the warning because it made the entire project look bad with all those warnings everywhere, and at this point it's just egos and politics from all sides of the argument.
I don't think there are that many actually maintained packages that will break in a merged environment. It's more about the theoretical issue and about principles than anything.
It started out as a technical issue (the invalidation of some core assumptions about the file system in critical packaging infrastructure), but it's so much more than that now. I think the conflict will blow over, but just like people are still advocating for the death of systemd it'll take many years.
I don't think this has caused as much tech debt as it all seems from the aggressive discussions. It's a problem with some packages and some very exotic system configurations (embedded stuff is great at creating those "technically correct and supported but we really shouldn't have encouraged this" edge cases) but for the vast majority of the users and maintainers the whole thing is in the past now.
In the Linux space there are so many things that actually matter, like the 5 second Firefox startup delay caused by Snap and the fact that GTK still lacks a proper thumb grid view after it's been a meme for so many years. This whole issue is kind of a useless thing to put so much energy into.
Qt has the same problem and, at this point, I doubt this will change at all in the next decade. Very few applications actually have any reason to use the default file chooser, and there are basically no developers who have any reason to modify it. If there were, they would have made the changes already sometime in the last "many years". The Snap issue is at least fixable with some caching.
That said, there is a clear trend in distros to move to merge these directories and I don't see why not. There are some niche use cases for different partitions containing different binaries and such, but like all niche use cases you're going to need to configure those yourself.
The opposition's argument seems to revolve around "we always did it this way so we can't do it any other way", really. This is the stuff that led us to a world where the most popular distro now packages the standard browser in a Snap package.