Original text:
Remove support for non-AEAD ciphers.  2. The cryptographic parameters of the session state are produced by the digest being signed are both the corresponding hash algorithm as defined in SHS.  When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest <del> output. </del>  Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond <del> to the "PureEdDSA" algorithms and not the "prehash" variants. </del>  rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list accordance with the requirements of RFC5246 when negotiating that version.  In particular: <del> TLS 1.2 ClientHellos may omit this extension. </del>  In TLS 1.2, the extension contained hash/signature pairs.  The pairs are encoded in two octets, so SignatureScheme values have implementation.  In particular, MD5 SLOTH and SHA-224 MUST NOT be used. <del> ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/ signature pairs.  However, the old semantics did not constrain the signing curve. </del>  4.2.3.

Reviewer comments:
The document was pretty crisp about the version downgrade protections, but was less good about the changes to signature schemes. I have made a few changes to the description of signature_algorithms that should improve that. In particular, I have made it clear that the RSASSA-PSS codepoints are also defined for TLS 1.2 and that they can be used there. That means that TLS implementations need to be prepared to accept PSS signatures. This also adds a section that points to the pieces that 1.2 implementations need to consider.
(Well, I think, strictly speaking, we need only lock down HashAlgorithm.) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges. I'm not sure how to write that kind of IANA consideration or I'd put together a PR. The end result should probably be something like s/Unassigned/Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards, all new signature algorithms that apply to TLS 1.2 must go through a backported SignatureScheme. (If we're not happy with that strong of a restriction, we could perhaps only burn HashAlgorithms 0x80 and up. Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range. Though 's PSS text already implies we'll be backporting SignatureSchemes, so the division probably isn't necessary? I dunno. I don't really care either way.)
Let's just lock down HAshAlgorithm. Can you submit a PR?

Revised text:
Remove support for non-AEAD ciphers. <ins> 1.3. This document defines several changes that optionally affect implementations of TLS 1.2: A version downgrade protection mechanism is described in server- hello. RSASSA-PSS signature schemes are defined in signature-algorithms. An implementation of TLS 1.3 that also supports TLS 1.2 might need to include changes to support these changes even when TLS 1.3 is not in use.  See the referenced sections for more details. </ins> 2. The cryptographic parameters of the session state are produced by the digest being signed are both the corresponding hash algorithm as defined in SHS.  When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest  <ins> output.  This codepoint is defined for use with TLS 1.2 as well as TLS 1.3.  A server uses RSASSA-PSS signatures with RSA cipher suites. </ins> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond  <ins> to the "PureEdDSA" algorithms and not the "prehash" variants.  A server uses EdDSA signatures with ECDSA cipher suites. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list accordance with the requirements of RFC5246 when negotiating that version.  In particular:  <ins> TLS 1.2 ClientHellos MAY omit this extension. </ins> In TLS 1.2, the extension contained hash/signature pairs.  The pairs are encoded in two octets, so SignatureScheme values have implementation.  In particular, MD5 SLOTH and SHA-224 MUST NOT be used.  <ins> ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature pairs.  However, the old semantics did not constrain the signing curve.  If TLS 1.2 is negotiated, implementations MUST be prepared to accept a signature that uses any curve that they advertised in the "supported_groups" extension. Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3), MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. </ins> 4.2.3.