And, in the modern world of big computers (desktops and laptops), it is not all that big of a deal (I don't actually know, but I would guess it's on the order of a few MB, maybe in the tens of MBs), and from what I can tell a lot of applications are already built statically for distribution to Windows and Mac OS X.
I agree with you on "big computers" to an extent. I just bought a temporary [1] laptop. It's beefy enough, but only has 2GB of RAM and 32GB of relatively slow flash storage [2].
Mobile broadband prices have been falling in Australia but it's still at the point where I have to thing before downloading anything >5MB.
[1]: http://www.pendo.com.au/pendopad/pendopads-windows-8/pendo11... (I didn't pay RRP)
[2]: Okay, okay, it's still eMMC, but it feels slow.
I do think changes in how shared libraries are shipped or managed may help. I've had ideas for ages around using cryptographic hashes but have no time to experiment with such things.
This bit me on the ass when Apple forced a libstdc++ update on OS X 10.3 with a new ABI, permanently breaking all C++ compilation on my Mac. Compiling C++ programs for 10.3 was still possible, but you needed a 10.4 machine, the latest Xcode, and compatibility libraries to do it.
I had similar problems on Linux and Solaris because of that transition. My own fault (actually my employer's) for assuming binary compatibility when it was never promised.
The ABI between g++ transitions is also platform and architecture dependent. Mac was PowerPC back then. Sun used Sparc. Not everything is always x86, even on Linux.
I still would characterize it a fairly stable ABI, not something that "can always break", especially compared with other vendors that break the library ABI every release.
[1] A new libstdc++ C++11 ABI was added in GCC 5.x but it is optional even in C++11 mode.