You should check if 'charset' is a string, and call Charset on it only if it is (a Charset may be passed directly in other email package interfaces, and so should be supported here as well.

The test doesn't need to cater for the fact that either b or B (or q or Q) are legitimate: we know which one the package is generating, so just test for that.

For the Message['To'], I wasn't clear.  What I would like is a test that includes non-ascii characters in the address part, *without* passing it through formataddr, to see what the package currently does with it.  This may in fact reveal an additional bug.  But, it is really out of scope for this issue, so you can just remove that test (sorry).

There should also be an update to the docs (Doc/library/email.utils.rst) documenting the API change.