Perhaps the whole PythonLabs crew should have an in-person brainstorming session to kickstart the goalmaking process?
Why should this be PythonLabs' internal brainstorm? We may be the only ones who get paid directly to maintain Python (part time, the rest is Zope work!), but we're not its only maintainers. This concerns us (active developers) all, because we're all limited resources.
What's Zope doing to handle this issue?
Assuming you mean "how is change in the Zope software handled" (rather than "how does Zope Corporation handle change in Python"), they have a rather different approach.
There's an effort to create a Zope 3 which is a total rewrite, (almost) completely from scratch. There's an explicit compatibility requirement for the end result, but that's only needed in the final phase -- while it's being created (with lots of help from the Zope community) it can do whatever it wants.
In the mean time, various previous Zope releases are still being maintained: I believe that both 2.4 and 2.5 are under active maintenance, meaning that micro releases are occasionally issued, and there's an effort underway to create a 2.6 release (again with community help).
While there's a striving for easy upgrading from 2.x to 2.(x+1), each new one (2.(x+1)) adds significant new features; I believe strict compatibility between 2.x and 2.(x+1) is not a goal (except at the storage level -- the database contents are sacred). I believe that it's very common for 3rd party products written against 2.x to require significant porting effort to work with 2.(x+1).
The www.zope.org site for example runs a very old version of Zope (I believe 2.3) because it's encrusted with much custom code that make an upgrade difficult. Instead, there's a completely new version in the works (new.zope.org).
--Guido van Rossum (home page: http://www.python.org/~guido/)