@notriddle, there are a number of factors which make a monorepo attractive and appropriate. I don't believe it's a good fit for me, however.
Monorepos are well-suited for monolithic projects, like linux, which are tightly integrated and are used "all at once." These products typically do not need to concern themselves with "out-of-project" code re-use. Is the kernel's DMAEngine, for example, really useful without the rest of the kernel infrastructure around it? Probably not.
Conversely, when the goal is to write a re-usable library or eight, it may be difficult to convince downstream consumers to ingest a monorepo. When all I need is the ability to read PNGs, I will likely opt for something like
GDAL. The latter is much arguably much more capable… but if I don't need spatial data support or the ability to read TIFFs, then all GDAL does is add API surface, code mass, and build headaches.
It has been my personal experience that drawing hard borders between projects leads to better-planned, better-versioned APIs with smaller surfaces. Projects which stand apart can evolve without too many constraints from their up- or down-stream dependencies. One substantial advantage of individual repos is the ability to specify versions "loosely." Consumers are not forced to use "whatever version was current as of time X" of every package or crate.
Human factors are also important here. A monolithic project probably has similar contribution guidelines and review procedures for every part of the codebase. There is probably a committee, a benevolent dictator, or such, who watches over the entire thing. If there is no such entity—perhaps because the parts of the system are too disparate to have a single stakeholder, or because they are never designed to all fit together—then there is trouble ahead. These projects likely do not belong together.
In my opinion, tightly-coupled projects can reap the benefits of sharing a repository. Loosely-coupled projects, which may lack a single purpose or an overarching maintainer of the "system of systems," probably should not.
Of course, the minute we start gluing projects together from multiple repositories, we start to need some kind of package manager.