RTFA, they say. Here' the FA is wrong -- the lectures are not owned by Microsoft, but are the personal property of Bill Gates who has made them available to Microsoft.

Multiple processes loading the same version of a side-by-side library can still share codepages. In practice there's only a few versions of each library.

Secondly, and more importantly, static linking means that if any library your program is using is found to be vulnerable, you must ship a new version of your program. With dynamic linking, the library can be updated separately.

In fact, this is one of the big use-cases of side-by-side: it comes with a policy redirection mechanism for servicing. Library authors can say "version X was vulnerable, so all apps using version X must use version X.1 which fixes the vulnerability", even if version X is only privately installed in the application's folder.

One thing to note is that you generally don't use library C side-by-side unless C's developer intended you, as they're usually the ones to provide the manifest that's used to refer to the library.

Global variables you'll have two copies of. But in general, you raise a salient point -- library C must be explicitly designed so that two versions can be loaded in the same process. Microsoft actually provides guidelines on how to get there: http://msdn.microsoft.com/en-us/library/aa374238(VS.85).aspx

A clean XP machine doesn't have the 2005 CRT on it. Apps need to carry the CRT if they're going to depend on it, same as always; the deployment needs haven't changed.
It's just that the needs may have been mostly hidden by implicitly relying on other products to be installed on the machine that carry the CRT themselves.
Since the pool of software linking against this new version is still fairly small, relying on an install from another piece of software is a bad bet.

Of course, if you do that, your application is vulnerable when bugs are discovered in the library.