Let's say I want to fork one of your monorepo modules and maintain a version for myself. It's hard. I might have to fork 20 modules and 19 will be unwanted. They'll be deleted, go stale, or I'll have to do pointless work to keep them up to date. Either way the fork and merge model that drives OSS value creation is damaged when what should be small, lightweight focused repos are permanently chained to the weight of arbitrary other code, which from the perspective of the one thing I want to work on is dead weight.

You can also just tell that monorepos don't scale because eventually if you keep consolidating over many generations, all the code in the world would be in just one or two repos. Then these repos would be so massive that just breaking off a little independent piece to be able to work on would be quite crucial to being able to make progress.

That's why the alternative to monorepos are multirepos. Git handles multirepos with it's submodules feature. Submodules are a great idea in theory, offering git repos the same level of composability in your deps that a modern package manager offers. But unfortunately submodules are so awful in practice so that people cram all their code into one repo just to avoid having to use the submodule feature for the exact thing it was meant to be used for...

Hm, I never had much issues with submodules. It seems just to be something that when one has understood it, one can use it, but it might seem scary at first and one needs to know, that a repo uses submodules at all.