I'd say the number of git repos on Earth that would encounter problems of that nature would be a vanishingly microscopic minority. Sure, it's a problem for those companies but it's not a problem for anyone else.
Vanishingly small in number, but quite significant in terms of the number of developers working in them.
All of the organizations that have outgrown git will have such incredibly specific requirements meaning nothing but a custom built tool will work for them.
The so called problem would also vanish if the monorepo was modularized and broken up into smaller repos.
That's probably a harder task for an existing monorepo that is too big for git than writing a replacement for git that works with a repo of that size.
The problem boils down to refactoring a large monolith. I feel like Git is a scapegoat for a much larger problem.
Let's say you started with a well factored set of code that is managed within your organization. What advantage is there to having multiple repos if you're not limited by your tools? Refactoring is easier within a single repo...
There probably will be a plethora of different hard issues to fix in such situations.
It's also easier to institute change in a dictatorship as opposed to a democracy (being a dictator that is :).
In my experience, code doesn't stay well factored unless there are technical hurdles that keep it so. That of course doesn't have to be a repo boundary, but in can be.
Objectively not true. Many (most?) are just using Perforce in an off-the-shelf configuration.
This reads to me as a failure of imagination. Any mid size game development shop is going to feel this pain - not just giants like Microsoft and Google. I believe the Unity Game Engine has a user base in the millions? Even a subset of that may be small in comparison to the entire developer population but by no means microscopic.