A crash is a segfault or equivalent.
Python 2.6 only gets security fixes.
PyAMF does not run on Python 3. Hence a problem with PyAMF is no evidence of a problem with 3.x. Separate tests/examples would be needed.

Changes are not bugs unless they introduce a discrepancy between code and doc. Please post a self-contained example that exhibits the behavior that you consider a problem. It should not just be a repeat of #11898. Then quote the section of the docs that says (or suggests) that the behavior should be different from what it is.

The PyAMF site says "PyAMF requires Python 2.4 or newer. Python 3.0 isn’t supported yet." Since 3.0 was deprecated 2 years ago with the release of 3.1, I strongly suspect that the statement was written before 2.7 was released a year ago. Library developers should not make open ended promises like 'or newer' -- certainly not without testing and revising as necessary with each new Python version.

If PyAMF was broken by planned, announced, and documented changed in 2.7, that is too bad, but it is a year too late to change 2.7. Like all new versions, it had public beta and release candidate phases when people could test their packages and make comments.

I believe what David is getting at is finding out for sure whether the change was intended or not.

The quote from the link you provide
  >msg += message_body
appears to be the programming error, already explained in #11898,
where msg is unicode and message_body is bytes with non-ascii bytes.

>>> u'a'+'\xf0'
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 0: ordinal not in range(128)
This is exactly the same error message that followed in the link, except that the position of the non-ascii byte. The fix is to not do the above.