Please be sure that I totally respect your work. Still, while I agree some of your points are right, I believe you're taking a shortcut here:
> For an example of a community that gets this: C. No one develops in K&R C anymore. However, there is still tons of code out there, even code inside of some core projects you use every day, that was written in K&R C and never needed to get serious modifications made.
The syntax evolved, but behind this syntax K&R C behaves in the exact same way, all the way up to the latest C revision. You can't say the same for old vs new classes, which behave in a not so subtly different way, and you can't say that either for the new str/old str, and indeed you propose a different name, which is perfectly legitimate, as they are different things.
The problem is also a vision of scale. I'd say the designed impact of python 3 breaking changes is not for next year, or even the next two years, but for the next 10-15 years. I think the decision came from the realization that there were retrospectively bad or overlooked design choices, and that they needed to be fixed, and thus cut out, now. The most critical things dropped from python 3 are actually stuff carried over from python 1. Python's design and philosophy is around a form of minimalism. The Zen of Python says:
Now is better than never.
Although never is often better than *right* now.
I'd say from anecdotal experience that every single python project I write today works on both 2.7 and 3.2. I sure wish python 3.2 received 2.6's from __future__ import unicode_literals, which would, along with 3.3, remove the biggest part of my headaches. The real problem, as stated, lies in the dependencies, and there's no denying that although you can compile K&R C today, such code was not written in a vacuum and certainly (recursively) relies on a bunch of libs that may or may not work today anymore (because of the code itself, the plaform, or the compiler evolving). It is also in plain sight today with Ruby, where a significant number of historical gems simply don't work anymore in 1.9.x (worse, some appear to work, and silently corrupt stuff, up to a point where it blows up. I'm looking at you mysql, which silently fails to transcode strings, the very situation Python introduced an "upfront error" breaking change).
The point I want to make is that the situation is simply not as clear cut as some want to make it. The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then? To which none of us has an answer. If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).