Change:
A single 0 byte which serves as the separator <del> If the authenticator request is present, the value "Hash(Handshake Context || authenticator request || Certificate)" </del> <ins> The hashed authenticator transcript </ins> <del> If an authenticator request is not present, the value "Hash(Handshake Context || Certificate)" </del> <ins> The authenticator transcript is the hash of the concatenated Handshake Context, authenticator request (if present), and Certificate message: </ins> <del> where Hash is the hash function for the handshake. </del> <ins> "Hash(Handshake Context || authenticator request || Certificate) " </ins> <del> A HMAC over the value Hash(Handshake Context || Certificate || CertificateVerify) if an authenticator is present, or Hash(Handshake Context || authenticator request || Certificate || CertificateVerify) where Hash is the hash function for the handshake, and the HMAC is computed using the hash function from the handshake and the Finished MAC Key as a key. </del> <ins> Where Hash is the hash function negotiated by TLS.  If the authenticator request is not present, it is omitted from this construction (that is, it is zero length). </ins> <del> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the version of TLS negotiated.  If an authenticator request is present, the signature algorithms used to choose the algorithm are taken from the "signature_algorithms" in the from the authenticator.  If there is no authenticator request, the signature algorithms are chosen from the "signature_algorithms" extension from the ClientHello used in the connection.  This is described in Section 4.2.3 of TLS13 and Sections 7.4.2 and 7.4.6 of RFC5246.  Alternative certificate formats such as RFC7250 Raw Public Keys are not supported.  The "server_name" RFC6066, "certificate_authorities" (Section 4.2.4. of TLS13), or "oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide certificate selection, with the extensions provided in the authenticator request taking precedence over the extensions provided in the connection handshake. </del> <ins> 4.2.3. </ins> <del> If an authenticator request was provided, the Certificate message MUST contain only extensions present in the authenticator request. Otherwise, the Certificate message MUST contain only extensions present in the ClientHello. </del> <ins> A HMAC HMAC over the hashed authenticator transcript, which is the concatenated Handshake Context, authenticator request, Certificate, and CertificateVerify: "Hash(Handshake Context || authenticator request || Certificate || CertificateVerify) " The HMAC is computed using the same hash function using the Finished MAC Key as a key. 4.2.4. An endpoint constructs an authenticator by concatenating serializing the Certificate, CertificateVerify, and Finished as TLS handshake messages and concatenating the octets: </ins> <del> The authenticator message is the concatenation of messages: Certificate || CertificateVerify || Finished </del> <ins> "Certificate || CertificateVerify || Finished " </ins> A given authenticator can be validated by checking the validity of the CertificateVerify message given the authenticator request (if

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.