Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo.

These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?