I seem to have been missing some context here.  I now understand that this is a regression relative to Python 2.x.  It seems to me that the translation from rfc822.Message to email.Message was done incorrectly.  In the 2.x code getheader returns only the value of the first header with the given name, in the 3.x code it returns the comma separated concatenation of the values of all headers with that name, and breaks the handling of default.

Any idea which handling of header values is actually the correct behavior vis-a-vis the http protocol?

Either way, the translation broke 'default', and that should be fixed, especially since we know there is 2.x code depending on the documented behavior, and the documented behavior hasn't changed in 3.x.  Since it is a regression, I'm inclined to think we can get away with fixing it without preserving backward compatibility with 3.1.2 (ie: it's a bug, and no one is likely to have written code to work around the bug, they'd report it instead as Walter did). But my opinion on that should perhaps be verified by appeal to python-dev, once we've agreed on what the correct behavior of the routine should be given multiple headers with the same name.

I'm adding hdiogenes and barry as nosy since they were the principle people involved in the translation, but they may not remember why this particular change was made.  As far as I can see the change is in the patch Barry applied but not in hdiogenes' original patch in the relevant issue (issue 2848), so there is probably some discussion missing from the issue.