Original text:
The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. <del> The "a=rtcp-mux" line MUST NOT be added unless present in the most recent answer. </del>  The "a=rtcp-mux-only" line MUST NOT be added. consistent with the existing DTLS association, if the association is being continued by the offerer.  If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. not used. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </del>  If this session description is of type "pranswer" or "answer", the following additional checks are applied: returned. If this m= section is new, begin gathering candidates for it, as <del> defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. Or, if the ICE ufrag and password values have changed, and it has not been marked as bundle-only, trigger the ICE agent to start an ICE restart, and begin gathering new candidates for the m= section as described in RFC5245, Section 9.1.1.1.  If this description is an answer, also start checks on that media section as defined in RFC5245, Section 9.3.1.1. </del>  If the m= section proto value indicates use of RTP: If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.3. <del> If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error. </del> For each specified RTP header extension, establish a mapping <del> between the extension ID and URI, as described in section 6 of RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </del>  If the MID header extension is supported, prepare to demux RTP streams intended for this m= section based on the MID header RFC3264, Section 6.1.  In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in I-D.ietf-mmusic- <del> sdp-bundle-negotiation, Section 10.2.  If any indicated media format is not supported, this MUST result in an error. </del>  For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload <del> type, as described in RFC4588, Sections 8.6 and 8.7.  If any referenced primary payload types are not present, this MUST result in an error. </del>  If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media.

Reviewer comments:
The local description can never be wrong, because it is constructed by the browser. I also explicitly added text to make clear that the mux state for any m= line cannot change.
LGTM
Section 5.8 describes the behavior of an implementation processing its own unmodified SDP. It contains significant error language that should have been removed when SDP munging was removed. In particular, please remove all of the following: • "If an error is returned, the session MUST be restored to the state it was in before performing these steps." • "If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error." • "If any indicated RTP header extension is not supported, this MUST result in an error." • "If any indicated media format is not supported, this MUST result in an error." • "If any referenced primary payload types are not present, this MUST result in an error." The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only.
I think Adam is right about this, but I wonder if this actually belongs elsewhere, so further study needed.
This is already duplicated. This seems to be a prohibition that is stricter than RFC 5761, and if we remove it here we have removed it generally, unless I have missed somewhere else we say it. This is not appropriate for remote descriptions. We say this in 5.9. >The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only. Yeah, I think Adam is right about this and it's probably the result of some section refactor
Made some progress on it. Editor discussion on the mux piece. Once an m= line has mux or non-mux negotiated, that's immutable.
LG with nits

Revised text:
The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line.  <ins> The "a=rtcp-mux" line MUST be the same as that in the most recent answer. </ins> The "a=rtcp-mux-only" line MUST NOT be added. consistent with the existing DTLS association, if the association is being continued by the offerer. <ins> RTCP multiplexing must be used, and an "a=rtcp-mux" line inserted if and only if the m= section previously used RTCP multiplexing. </ins> If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. not used. If the RTP/RTCP multiplexing policy is "require", each m= section  <ins> MUST contain an "a=rtcp-mux" attribute.  If an m= section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied: returned. If this m= section is new, begin gathering candidates for it, as  <ins> defined in RFC5245, Section 4.1.1, unless it is definitively being bundled (either this is an offer and the m= section is marked bundle-only, or it is an answer and the m= section is bundled into into another m= section.) Or, if the ICE ufrag and password values have changed, trigger the ICE agent to start an ICE restart, and begin gathering new candidates for the m= section as described in RFC5245, Section 9.1.1.1.  If this description is an answer, also start checks on that media section as defined in RFC5245, Section 9.3.1.1. </ins> If the m= section proto value indicates use of RTP: If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.3.  For each specified RTP header extension, establish a mapping  <ins> between the extension ID and URI, as described in RFC5285, Section 6. </ins> If the MID header extension is supported, prepare to demux RTP streams intended for this m= section based on the MID header RFC3264, Section 6.1.  In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in I-D.ietf-mmusic-  <ins> sdp-bundle-negotiation, Section 10.2. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload  <ins> type, as described in RFC4588, Sections 8.6 and 8.7. </ins> If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media.