That is just a best practice for published interfaces (allowed to be used outside of your repositories). E.G. using a different build, main example being APIs available for customers) Not all interfaces need (really "must not") to be published. For "private" interfaces it is an advantage to be able to refactor them easily and also being able to rollback those changes easily if needed. Without a mono-repo that becomes difficult. You basically need an additional layer to "stitch" commits together. You could question why that makes sense because it would just emulate mono-repo behavior.

If an interface spans repos it isn't private.

I assume you are not creating some strawman every source code file is in a separate repository. That would be insane and nobody does that. If you are in a mutli-repo world, then how your break your repos up is an important decision. There are interfaces that are allowed to use within one repo that you cannot use in others, which allows things that should be coupled to be coupled, while forcing things that should be more isolated to be isolated. This is the power of the multi-repo: the separation of what is private vs public is enforced. (which isn't to say you should go to multi-repo - there are pros and cons of both approaches, in the area of where and interface can be used multi-repo gives you more control, but there are other ways to achieve the same goal)

Not sure I understand what you say. But a repo for a library that is used only internally in an application does not need to be published to "customers"(real external customers or internal customers such as another microservice). Therefore interfaces of this library can be changed "at will" as long as all internal users are adapted.

There is no rule about how much is in an individual repo in a multi-repo setup. Sometimes multi-repo setups have more than one library in a repo.

Even if we take the one library example you have, the library has source file A.c and B.c (I'm using C as an example, but this should apply to any language). A is the main interface, with B helper functions. With a mono-repo it is easy for someone else to use B even though that is not supposed to be the interface, with a mutli-repo setup the interface to B isn't published, and so only A can get at it. Of course the point to this is if B.c is wanted as an interface you get notice of that need and can review the interface to make sure it is clean.

In a more complex variation of the above, related libraries in the same repo LibX and LibY can both use B.c, but libraries in other repos can't get at B.c.

Does this matter to you? That is your decision. In a simple situation it won't. In a complex project it needs to because complexity is the enemy.

Again, mutli-repo is only one possible solution to this problem. There are many ways to solve this problem, each with pros and cons. You need to figure out what is the best compromise for your situation, and then mitigate the cons to your choice. There is no perfect answer. I've touched on one a few of the pros and cons of them - and there are probably some that don't even apply to me but will to you.