Backwards compatibility [Wishlist, not initiative]

I know that this topic was discussed before, and not once. Yet if I would raise core initiative, it will be about backwards compatibility.
We love Drupal for the cool new stuff. Regretfully, this cool new stuff automatically marks old stuff, which we believed to be cool just yesterday, as outdated. This happens again and again, and there are already signs that Drupal 8 will not be an exception.
I fully understand that there are serious reasons for making changes in core that are not compatible with existing code. From the other hand, what's the use in brand new shining core, packed with blows and whistles, if it is not supported by contrib?
The wider adoption of Drupal will go, the worse the compatibility problem will become. Need to rewrite own custom code every 3 years or so can kill the small company, and force enterprise to choose more "stable" platform.
The question is, is it possible to innovate, but allow existing code to run even in the new environment?
If it is possible to have in D8 core optional compatibility layer, which will allow D7 modules to work as if they are in D7 core? For sites built from scratch for D8, this will not have any overhead, but make upgrade path much smoother.
Compatibility layer could, for example, rely on PHP 5.3 namespaces. Let's say, D8 code resides in Drupal8 namespace, and compatibility code in D7 namespace. Benefit: it is possible to have functions with the same name, but different parameter sets. Yes, it requires PHP5.3, but many distribution vendors have already dropped support for earlier version, and it is much easier to upgrade PHP, than to rewrite tons of existing code.
Of course, this could be tricky, but... aren't tricky things cool?