Yes, and I pointed out one of the reasons for not supporting backwards compatibility in https://news.ycombinator.com/item?id=18819491 . There are many others of course.
It's in a parallel thread because it's a response to t0mbstone's statement that Python developers should have done more work to support backwards compatibility.
I am not saying that Python should "deprecate every old functionality always", but that is what dragonwriter seems to be arguing.
dragonwriter made a different argument about why to drop backwards compatibility, based on an interpretation of the Zen of Python. My response on this thread is to say that that interpretation of the Zen of Python is not valid, or at least weak, given that it does not explain Python's own development history.
Something that I am sure that you agree with.
I don't see where your views disagree with mine.
> but Python does support old functionality
is completely compatible with "should deprecate functionality that could have easily been supported". There should be only one way to do it is correct. Under the zen, you should bias towards deprecation. That doesn't mean deprecate every old functionality always. Indeed if there are compelling reasons not to deprecate something (the maintenance cost truly is zero, it is infeasible, the new functionality only covers a subset of uses, etc.) you shouldn't!
The python mailing list and peps have a good bit of discussion about most backwards incompatible changes from py2 -> 3 (and more recent ones, like adding new keywords).