Well, it depends. If you have an API with only a few direct usages, you might do it in a single commit. Changing API's that have many usages is difficult to do atomically even if you have a monorepo, due to the difficulty of getting approvals and the risk you'll have to roll it back.

Often it's better to introduce a new function and migrate usages to it across multiple commits.

Either way, it's on you to fix everyone else's code, which is a different mindset from releasing a library and letting downstream users do the migration themselves when they feel like it.

Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical necessities) have lead to all the languages being twisted into an odd hybrid of the dependency management style of each other. Things are very complicated to manage and some teams are trying to leave their current and best known language for a language with internal champions/leaders that are louder, more opinionated, and better positioned politically. A lot of this is due to a lack of wide familiarity with intermediate git skills and a fear of learning the tool. So many of our solutions to this problem are to automate things under the rug, which is why every language ends up being handled generically using medium grade internal tooling instead of best of class industry standard tooling. Most of these issues can be boiled down to an avoidance of pain rather than a championing of the best technical choice.

Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need.

The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.

Not at all. Monorepo is merely a detail around VCS and it does not remove complexity and the need for versioning.