Amazon has a repo per package model, but has a meta-versioning system (called version sets) that tracks revisions of packages built together and a way for declaring package dependencies. So in some sense you're building your own monorepo out of a bunch of packages (usually by branching off a parent version set).

It fulfills a lot of the same goals of having a monorepo in terms of scaling a large organization, while having somewhat different pros and cons.

We don't, and it's hell. I may make a change to X, but some other developer doesn't know it, and then one day when he makes a change to X and tries to pull those changes into Y, now he has to change the bits of Y which are affected by my changes as well as his.

I would love to have a monorepo, although I'd advocate for branch-based rather than trunk-based development. Yes, merges can be their own kind of hell, but they impose that cost on the one making breaking changes, rather than everyone else.

That just means that no one makes big breaking changes even if they night be necessary.

To me the defining aspect of a monorepo is storing apparently unrelated code in the same repo, which is highly non-intuitive.

Most unicorns don't have mono repos.