Maybe in java world it was different but when i wrote c++ and go code there breaking existing apis was extremely frowned upon and if they had to do it people usually sent you automated code edit PRs for this
I can attest. I work at a similar megacorp with a very large megarepo. If you commit a change that breaks any kind of test, anywhere, that shit is getting reverted very rapidly. If you MUST make a breaking change, congradulations, you get to update all of your users code too.
This is about company culture, not the programming language. When someone breaks their API and someone else's code stops working as a consequence, will the first person get told to fix their API, or will the second person get told to fix their application?
Some companies may have a consistent policy about this, in other companies it may depend on which team happens to have more political power.
At least during my time there nobody was introducing breaking (at compile time) api changes wily-nily. What did happen was people would deprecate (or “sunset” as pms loved to call it) a runtime api that ppl depended on - i.e shutting down some servers. So splitting the monorepo would do nothing here unless you’re willing to run those services yourself.