Original text:
containing a single certificate and set of extensions. A set of extension values for the CertificateEntry.  The <del> "Extension" format is defined in extensions.  Valid extensions include OCSP Status extension (RFC6066) and SignedCertificateTimestamps (RFC6962).  An extension MUST only be present in a Certificate message if the corresponding ClientHello extension was presented in the initial handshake.  If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry. </del>  If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not

Reviewer comments:
The peer must advertise extensions before they can be sent with a certificate message.
I fixed it with a period.
statusrequest and signedcertificatestatus timestamps are allowed in the CertificateRequest message according to URL Certificate extensions (URL) however say: Is this also the intended behavior for client certificates, or should it instead require extensions to be advertised in CertificateRequest? (This is relevant for future extensions.) No idea why a client would bother sending SCT or statusrequest extensions, but that is not forbidden by the TLS 1.3 spec. The status_request (RFC 6066) and extensions are written such that it seems unusable in client certs though.
I'd say it's both - for those extensions to be in client side Certificate message they need to be both in Client Hello and in Certificate Request. That's because any extensions in Certificate Request must have been first advertised in Client Hello
That's not correct. You can advertise stuff in CR that's not in CH (e.g., X.509 OIDs). Peter, good catch. PR welcome.
NAME that's rather ugly - to this point only the cookie extension was of a "you support it even if you don't advertise it", I don't like adding more exceptions to that rule...
It's been this way for some time. URL
It's much simpler this way. As in the text EKR pointed to, extensions come in request/response pairs, so there is only one kind of flow to worry about. In your version, client certificate extensions have this weird three-phase bit which ends up meaning extra logic in implementations. This additionally is more flexible. Suppose I am willing to send an SCT on my client certificate, but I don't have anything useful to do with the server one. (The inverse is more likely for SCTs but consider a future bit of certificate metadata.) In your version, there is no way to distinguish "I want an SCT" from "I won't explode if you request one of me".
That's what I meant - the Certificate Request ones are not described as "unsolicited". I don't think this is a useful distinction to make. But I digress. If we make all Certificate Request extensions unsolicited, that's fine by me. But I think that it's a significant change from TLS 1.2, and should be documented as such.
TLS 1.2 had no extension mechanism for CertificateRequest: URL
CertificateRequest extensions were intended to be unsolicited, yeah.

Revised text:
containing a single certificate and set of extensions. A set of extension values for the CertificateEntry.  The  <ins> "Extension" format is defined in extensions.  Valid extensions for server certificates include OCSP Status extension (RFC6066) and SignedCertificateTimestamps (RFC6962).  Extensions in the Certificate message from the server MUST correspond to one from the ClientHello message, extensions in the Certificate from the client MUST correspond with an extension in the CertificateRequest message from the server.  If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry. </ins> If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not