How exactly a system might break by updating glibc?

In general, binaries that were compiled for an older glibc version will run fine on a system with a newer glibc, as glibc is backward-compatible and handles automatically changes to its application binary interface (ABI). It achieves this wizardry by using symbol versioning, where basically to each symbol is attached a tag specifying its glibc version.

In case of semantics changes to function calls, glibc will include two versions, one for the old semantics and another for the new semantics, so each function is tagged with its version. The linker will consider both versions as two distinct functions.

This sophisticated mechanism is required since glibc is not one file but consists of many pieces (more than 200 shared libraries).

The backward-compatibility of glibc versions is under constant tracking. You may consult the ABI Laboratory report for API/ABI changes review for glibc. The report is generated by the abi-compliance-checker and abi-tracker tools.

For your question:

So if I'm overwriting with a newer libc.so.6 with additional glibc ABI versions inside it, how does it break older apps or leads system to breakage? Or doesn't it...?

Glibc compatibility is not fool-proof, but I believe that you will have to go way back to products compiled on quite old Linux versions to break it. I would also say that products may break not only because of glibc when run on versions of Linux different than where they were compiled.

So the best answer I can give is :
"It's not supposed to break anything, and there is an excellent chance that it won't".

For more information, see:

• The GNU C Library With Versioned Interface
• ABI compliance checker Notes
• ABI Policy and Guidelines