> This attitude will lead to a total breakdown of the development process over the long term.

As evidenced by Microsoft following the one repo rule and not being able to release any new software.

Wait, what ?

The text I quoted had nothing to do with monolithic repos.

The linux codebase exists in stark contrast to your claim. Assuming your claim is that broken up repos is the better way.

No it doesn't. I think you are thinking of the kernel, which is separate from all the distros.

Linux by itself is just a kernel and won't do anything for you without the rest of the bits that make up an operating system.

Then I'll point to the wide success of monolithic utilities such as systemd as evidence that consolidating typically helps long term.

Which is to say, not shockingly, it is typically a tradeoff debate where there is no toggle between good and bad. Just a curve that constantly jumps back and forth between good and bad based on many many variables.

systemd is also completely useless on its own. It still needs a bootloader, a kernel, and user-space programs to run.

When it comes to process managers, there is obviously disagreement about how complex they should be, but systemd is still a system to manage and collect info about processes.

The hierarchical merging workflow used by the Linux kernel does mean that there's more friction for wide-ranging, across-the-whole-tree changes than changes isolated to one subsystem.

Isolated changes will always be easier than cross cutting ones. The question really comes down to whether or not you have successfully removed cross cutting changes. If you have, then more isolation almost certainly helps. If you were wrong, and you have a cross cutting change you want to push, excessive isolation (with repos, build systems, languages, whatever), adds to the work. Which typically increases the odds of failure.