Seeking the endgame for Debian's /usr merge

It depends on both the workplace and the specific change being made. At Google (my workplace), large-scale changes are typically coordinated in a centralized fashion, and the most important rule is that you can't break existing tests or functionality. This is possible because Google uses a monorepo, so we have the ability to find all of the tests you potentially affected and re-run them. It would be illegal to break a bunch of tests and then tell the affected teams "fix it yourself." The person making the breaking change would be asked (told) to back it out, fix the tests, and try again.

More complicated changes are sometimes made in a top-down fashion, but this tends to be much slower and less efficient, and is usually only done for things that require a lot of subject-matter expertise and individualized judgment (often to the point where each individual team will be writing a separate design document about their transition process and all the weird pain points they ran into). There is also a degree of managerial discretion in terms of exactly who works on which projects, and in what order, so these mandates may not always be the top priority.

The difference boils down to "who the organization is in service of".

In businesses, in a sane situation (which not all situations are sane), the goal is to serve their customers. The customers have what the business wants and to get it they need to convince the customer that it's worth it to give it to them. So they try to identify the needs of customers, which is not a easy task. Once they have some needs identified then they need to figure out what it is worth to the customers... how much customers are willing to spend on fulfilling that need. Which is even harder. It's nearly impossible to get that right every time. Lots of products fail because of this.

Once the business leaders have those things sussed out as well as possible then it is up to the engineers to try to make it a reality. They have to figure out a solution that costs low enough to be profitable. Not just in terms of money or capital investment, but in terms of time. Sometimes it's not realistic and sometimes it is. But that is how "in service of a customer" should work in most situations. Profit/loss is how you determine how good of a job you are doing.

In the case of The Debian Project their "customer" is The Debian Project. People join and work on the project for the sake of the project and themselves. The cost is mostly individual/personal investment of time and effort into the project. And profit is determined by how much individual/personal benefit/fulfillment they derive from the project. What second and third parties derive from the project is almost incidental in comparison to what the maintainers get out of it.

Since the costs and profits are so "squishy" in nature.. it makes proper accounting mostly impossible. So it is very difficult to figure out how well the project is doing at serving itself. It makes for a tight balancing act between how much the project needs to keep people happy versus how much work they impose on other people in the project all the while fulfilling the technical requirements.

It is a difficult thing to get right. And it is a testimony to the governance model of Debian that they get it close enough to being right to survive so long. It is quite remarkable.