Reading the ABNF for the extended parameter values in RFC2231 reveals that they should not be quoted:

   extended-initial-value := [charset] "'" [language] "'"
                             extended-other-values

   extended-other-values := *(ext-octet / attribute-char)

however, set_param (really _formatparam) will always quote them unless requote is set to false. The fix is probably to force quote in _formatparam to False if faced with RFC2231 values, since they should never be quoted (and should not contain characters requiring quoting),

Hmm.  The RFC text says:

   Note that quotes around parameter values are part of the value
   syntax; they are NOT part of the value itself.  Furthermore, it is
   explicitly permitted to have a mixture of quoted and unquoted
   continuation fields.

So this looks more like a bug in the RFC to me.

Reading the RFC again, I think you are right.  The quoted vs unquoted sounds like it refers to the *n vs the [*n]* forms, and the latter doesn't use quoted strings but % encoding.

I'm attaching a patch that adds some tests and fixes this.  It's a visible behavior change so it won't be backported.  Clearly mailers accept the quoted form, but we prefer to be strictly RFC compliant on output.  The behavior change is that whereas previously unquoted values on parse got quotes added on serialization, now quoted values on parse will lose their quotes on serialization.

I take it back.  Previously quotes didn't get added if they weren't already there.  So my simpleminded fix may not be the best choice.

No, I was wrong.  This would only be an issue when a parameter's value is changed, and at that point we should be producing correctly (un)quoted values no matter what the original quoting of the individual value was.

So I've applied the patch in r87479.