Personally, I hate the way Linux releases are numbered (I can never tell which one is stable and which one isn't). But I could get used to it if we used the micro version number to indicate stability -- in particular, 2.2 would be experimental, and 2.2.1 and following would be stable; 2.3 would be experimental, and 2.3.1 stable.
Sounds quite workable, as long as we never want to do "bug-fix" point releases for experimental/bleeding-edge versions. The Linux folks do several experimental A.B (with B being odd, meaning experimental).N, but then Linux kernel/modules/drivers ARE an order of magnitude larger than Python, so we may not have analogous needs -- I dunno.
Or we could stay longer in beta.
Yes, library changes should be OK, as long as they don't alter behavior of code which used to run (without specific BDFL proclamation and prominent notice). I personally wouldn't mind if some good-intention wording about not breaking existing doctests (e.g. no change in wording of error messages) snuck in, but then I'm a doctest junky.
I don't think so. Doctest is extremely picky, on purpose, and a breaking doctest doesn't mean that regular apps will break.
Yes, public perception issues are to some extent paramount to ensure this slight variation has the intended effect.
Your freedom to experiment as well as public perception might be enhanced by some explicit mention that the first (.1) stable release does not guarantee 100% compatibility with the immediately previous bleeding-edge/experimental release, so you can (within some common-sense bounds) try putting something in 2.X and then taking it away in 2.X.1 if it didn't work. I.e., stability being guaranteed 2.X.1 -> 2.X.2 and so on, but not necessarily 2.X -> 2.X.1, just as not necessarily 2.(X-1).N -> 2..X.1.
Other folks more adept at marketing than me may come up with other ways to help public perception of 2.X.Y as "good, solid, stable, NOT old, dusty, junky" and thus helping this variant on "dual-track" fulfil its role.
Well, we can probably ride some of the common fear of X.0 releases. (Though we'd continuously have to explain that for Python, 2.X corresponds to X.0 in other vendors' numbering. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)