Change:
respond with an empty Certificate message, denoting no client certificate. <del> Note that verifying a connection for the public name does not verify it for the origin.  The TLS implementation MUST NOT report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server. These connections are only used to trigger retries, as described in handle-server-response.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. </del> <ins> Note that authenticating a connection for the public name does not authenticate it for the origin.  The TLS implementation MUST NOT report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server.  These connections are only used to trigger retries, as described in handle-server-response.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. 5.1.4. If the client attempts to connect to a server and does not have an ESNIKeys structure available for the server, it SHOULD send a GREASE I-D.ietf-tls-grease "encrypted_server_name" extension as follows: Select a supported cipher suite, named group, and padded_length value.  The padded_length value SHOULD be 260.  Set the "suite" field to the selected cipher suite. Set the "key_share" field to a randomly-generated valid public key for the named group. Set the "record_digest" field to a randomly-generated string of hash_length bytes, where hash_length is the length of the hash function associated with the chosen cipher suite. Set the "encrypted_sni" field to a randomly-generated string of 16 + padded_length + tag_length bytes, where tag_length is the tag length of the chosen cipher suite's associated AEAD. If the server sends an "encrypted_server_name" extension, the client MUST check the extension syntactically and abort the connection with a "decode_error" alert if it is invalid.  If the "response_type" field contains "esni_retry_requested", the client MUST ignore the extension and proceed with the handshake.  If it contains "esni_accept" or any other value, the client MUST abort the connection with an "illegal_parameter" alert. Offering a GREASE extension is not considered offering an encrypted SNI for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established without ESNI. </ins> 5.2.

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.