Monorepo is great if you're really good

In that context, if a thing is tough but has value, you make a path to it. First make the tools consistent, and then make people consistently use the tools. The more predictable the system becomes (predictability is the opposite of magic!), the more you insist on people using it. Pushback is a kind of feedback, and you have to address at least some of the concerns of people who refuse ('meet me halfway here').

Someday it will shock no-one to say that Git is not the best of all possible version control tools. If this is difficult, it may not be the people. Maybe it's time to start thinking about the next version control system?

SVN had some pretty decent facilities for monorepos. Some people will tell you that Git traded some of these features for others, but looking through the information architecture documentation for git, I don't think I can agree. Some of that information is there, it's just maybe not packaged for consumption.

You don't want people favoring starting new work while someone else is flailing on old work. The fact that they started this two weeks ago indicates it was probably higher priority than whatever you might start today. If today's work is an emergency (eg, if we could go back in time, we'd have started this immediately) then sure. But barring extenuating circumstances, go help Paul. He's been staring at that code for weeks and making no progress.

I think having a rule for how many branches/forks whatever you want to call them, can exist at once might be a good idea. Every time another opportunity to use a branch comes up, the older reasons have to defend their continued existence. Having to explain yourself over and over is a form of positive peer pressure, if potentially a little passive-aggressive (solution: use an assertive person to be the messenger).

When the right boundaries reveal themselves, you can divide the code up. But who is to say those will still be the right ones in ten years?

If you divide the source code into separate repositories before getting the boundaries right, there's a tremendous amount of friction built into the system preventing the problem from being addressed. Each repository has its own actors, cycles, and version control history, and you break two of those when you start trying to move code across project boundaries. So people just hit things with a hammer or steal functionality (three modules with a function that ostensibly does the same thing but with different bugs).

One of the things I see over and over again is people conflating one repository with one lifecycle. One binary. It's possible to have a monorepo with multiple build artifacts. The first monorepo I ever worked on had 60 build artifacts, and it worked pretty well (the separate artifacts weeded out a lot of circular dependencies).

I can still get inter-version dependency sanity checks with a monorepo. When I am writing new code I can have everything talk to localhost (master@head) or I can have it talk to a shared dev cluster (last labelled version) or some of both, allowing me to test that I haven't created a situation where I can't deploy until I've already deployed.

At the same time that Windows NT was being claimed as a microkernel, Linux was outperforming and had a reputation as being more reliable. Ditto with Mach. And GNU Hurd famously was hard to get running at all.

QNX is highly reliable, but is also a specialized use case.

Stop it and focus on one single web app instead that anyone can run. Unless your app is going to be in the top 10 that people can't miss downloading.