Original text:
media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. <del> The media formats in the answer MAY include codecs present in the offer that were discarded in a previous offer/answer exchange. This is necessary for compatibility with third- party call control and SIP use cases. </del> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5. the negotiated session descriptions by following the steps mentioned for the "have-local-offer" state above. <del> In addition, for each non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current remote description, if any: </del>  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST <del> only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated transceiver.  Note that non-JSEP endpoints are not subject to these restrictions, and might offer media formats that were not present in the most recent answer, as specified in RFC3264, Section 8.  Therefore, JSEP implementations MUST be prepared to receive such offers. </del>  Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in <del> the same order as in the current local description. </del>  The RTP header extensions MUST only include those that are present in the most recent answer. <del> The RTCP feedback extensions MUST only include those that are present in the most recent answer. </del>  The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line.

Reviewer comments:
any guess on what happened to these that caused them to not go in ?
They were somehow targeted to a branch other than master, and that branch was never merged
LGTM but you have a conflict

Revised text:
media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences.  Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5. the negotiated session descriptions by following the steps mentioned for the "have-local-offer" state above.  <ins> In addition, for each existing, non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current local or remote description, as appropriate: </ins> The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST  <ins> only include media formats which have not been excluded by the codec preferences of the associated transceiver, and MUST include all currently available formats.  Media formats that were previously offered but are no longer available (e.g., a shared hardware codec) MAY be excluded. </ins> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in  <ins> the same order as in the most recent answer.  Any media formats that were not present in the most recent answer MUST be added after all existing formats. </ins> The RTP header extensions MUST only include those that are present in the most recent answer.  <ins> The RTCP feedback mechanisms MUST only include those that are present in the most recent answer, except for the case of format- specific mechanisms that are referencing a newly-added media format. </ins> The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line.