Most of the time, I have a repo be an individual unit of testing. I.e. if the python client is broken, does that mean that the go client is broken as well? A large part of this is because its much easier to support testing multi-repos than mono-repos. Multi repos are generally easier to test because you run the entire suite of tests on every pull request whereas in a mono-repo you have to figure out which tests need to be run. All this isnt to say that its impossible (or not beneficial), but that its easier to have multiple repos with the current testing infrastructure (specifically looking at Jenkins). Another difficulty with mono-repos is merging code when something is broken, how do you know whether you should merge or wait for the bug to be fixed?

Is it? The Google repo posted by 'orangea is maybe the first one I've seen.

I mean, let's flip it around: when I need a lib for language X, why would I want to download it also for languages V, Y, and Z (+ all language-specific cruft)? Especially in this day and age, when dependency management in project involves build systems pulling repos automatically?

Or, put another way, library is one project. Python wrapper/client is a different project. Go wrapper/client is yet another project. Etc.

I can't think of any library for which this is the case, could you give some examples?

In this case, the project (at least from the Go standpoint) is broken into multiple sub-projects, each within their own repo. In Go Land, you would more typically see each component library put in its own subdirectories off of the main repo. The main repo could contain libraries for multiple languages or just one, but the subcomponents would be organized as subdirectories, not separate repos.