Original text:
implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension.  The "extension_data" field of these extension contains a SignatureSchemeList value: In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept.  In TLS 1.3 the former is expressed by sending <del> the "signature_algorithms" extension.  The latter is expressed by sending the "certificate_authorities" extension (see certificate- authorities). </del>  Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's <del> "signature_algorithms" extension. </del>  The "server_name" RFC6066 and "certificate_authorities" extensions are used to guide certificate selection.  As servers MAY require this extension, when applicable. All certificates provided by the server MUST be signed by a signature <del> algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see signature-algorithms).  Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. </del>  If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash <del> algorithm in general, but MAY do so if the "signature_algorithms" extension provided by the client permits it, and MUST NOT do so otherwise. </del>  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort Signature Algorithms ("signature_algorithms"; signature- algorithms)  Negotiated Groups ("supported_groups"; negotiated-groups) Key Share ("key_share"; key-share)

Reviewer comments:
In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.

Revised text:
implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. <ins> Implementations which have the same policy in both cases MAY omit the "signature_algorithms_cert" extension. </ins> The "extension_data" field of these extension contains a SignatureSchemeList value: In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept.  In TLS 1.3 the former is expressed by sending  <ins> the "signature_algorithms" and "signature_algorithms_cert" extensions.  The latter is expressed by sending the "certificate_authorities" extension (see certificate-authorities). </ins> Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's  <ins> "signature_algorithms"/"signature_algorithms_cert" extensions (see signature-algorithms). </ins> The "server_name" RFC6066 and "certificate_authorities" extensions are used to guide certificate selection.  As servers MAY require this extension, when applicable. All certificates provided by the server MUST be signed by a signature  <ins> algorithm advertised by the client, if they are able to provide such a chain (see signature-algorithms).  Certificates that are self- signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. </ins> If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash  <ins> algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise. </ins> If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort Signature Algorithms ("signature_algorithms"; signature- algorithms) <ins> Signature Algorithms Certificate ("signature_algorithms_cert"; signature-algorithms) </ins> Negotiated Groups ("supported_groups"; negotiated-groups) Key Share ("key_share"; key-share)