I linked but it was in an edit. The concrete paragraph is:

>  Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

This means the interface could fulfill those MAY requirements to change order of headers for example if editing is to be provided via such an interface.

However as it MUST be possible to combine the header fields into one "field-name: field-value" pair and the interface documents exactly that relationship (see the wording of the docblock), this normalization should be expected (and requested by the standard as default, and differentiations to that additionally outlined).

I'm not speaking so far about Set-Cookie as those are non-standard compared with HTTP RFC 2616 and need special-case treatment which should be addressed by an interface of it's own.