Whether 206 and 201 are HTTP success responses is not the question at hand.  Given that the 206 behaviour was changed, I agree that other success responses should also be considered (certainly seems a mistake that e.g. 203 was not added at the same time as 206), and indeed nobody has done that.  But I think backwards compatibility, the semantics of the various response codes and of urllib2, and ease of understanding, are more important than you seem to assume.

I don't see a patch.  In what way exactly do you propose urllib2 should be changed?  Note that it's not completely obvious: e.g. a 201 received by a plain-urllib2 client would be an erroneous server response, because urllib2 is designed only for retrieving URLs, and is not intended to be a generic HTTP client.  Also note that clients based on urllib2 that do support PUT, such as the Atom client you refer to, can easily implement the modified 201 handling themselves.  So on the face of it, the particular issue you raise is a bug in that code, and not in urllib2.

Of course, your derogatory remarks about authors / bug-fixers won't persuade anybody of anything, or get any work done.