Section 3.6.6 says:

   Resent fields are strictly informational.  They MUST NOT be used in
   the normal processing of replies or other such automatic actions on
   messages.

Further, since there is no specified order for the headers within a block, there is no deterministic algorithmic way to determine where one block ends and the next begins.  A human (or a well thought out set of heuristics) can almost always figure it out, but it isn't guaranteed to be non-ambiguous.

The conclusion on the email-sig is that we should do the right thing when it is unambiguous (no or only one set of Resent- headers), and throw a ValueError if there are two copies of any Resent- header (refuse to guess).  For 3.3 we could implement heuristics and provide an option to turn them on, but that is an API change and so can't go into the 3.2 fix.

You have a good point about the method mutating the object passed to it.  This will probably come as a surprise even if documented, so it is indeed probably better to ensure that the object is unchanged after the call.  This can be done by mutating and restoring the object, but that would (I presume) not be thread safe.  Better would be a generator option to skip bcc fields, but that again is an API change.  I suppose that making a shallow copy of the Message object will be safe and not too inefficient.  Hopefully it will work :)

There are unresolved release blockers for the 3.2.1 RC, so we have at least a week to get this fixed and still make 3.2.1.  Do you want to update your patch?