Original text:
2. <del> This informational status code indicates the client that the server is likely to send a final response with the headers included in the informational response. </del>  A server MUST NOT include Content-Length, Transfer-Encoding, or any <del> hop-by-hop headers (RFC7230, section 6.1) in the informational response using the status code. A client MAY speculatively evaluate the headers included in the informational response while waiting for the final response.  For example, a client may recognize the link header of type preload and start fetching the resource.  However, the evaluation MUST NOT affect how the final response is processed; the client must behave as if it had not seen the informational response.  A client MUST NOT process the headers included in the response as if they belonged to the informational response. </del>  An intermediary MAY drop the informational response.  It MAY send <del> HTTP/2 (RFC7540) push responses using the information found in the informational response. </del>  3. <del> Clients may have issues handling Early Hints, since informational response is rarely used for requests not including an Expect header (RFC7231, section 5.1.1). </del>  <del> An HTTP/1.1 client that mishandles the informational response as a final response is likely to consider all the responses to the succeeding requests sent over the same connection to be part of the final response.  Such behavior may constitute a cross-origin </del>  information disclosure vulnerability in case the client multiplexes requests to different origins onto a single persistent connection.

Reviewer comments:
... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).

Revised text:
2.  <ins> The 103 (Early Hints) informational status code indicates the client that the server is likely to send a final response with the headers included in the informational response. </ins> A server MUST NOT include Content-Length, Transfer-Encoding, or any  <ins> hop-by-hop header fields (RFC7230, section 6.1) in a 103 (Early Hints) response. A client MAY speculatively evaluate the headers included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target resource. However, this MUST NOT affect how the final response is processed; when handling it, the client MUST behave as if it had not seen the informational response.  In particular, a client MUST NOT process the headers included in the final response as if they belonged to the informational response, or vice versa. </ins> An intermediary MAY drop the informational response.  It MAY send  <ins> HTTP/2 (RFC7540) server pushes using the information found in the 103 (Early Hints) response. </ins> 3.  <ins> Some clients may have issues handling 103 (Early Hints), since informational responses are rarely used in reply to requests not including an Expect header (RFC7231, section 5.1.1). </ins>  <ins> In particular, an HTTP/1.1 client that mishandles an informational response as a final response is likely to consider all responses to the succeeding requests sent over the same connection to be part of the final response.  Such behavior may constitute a cross-origin </ins> information disclosure vulnerability in case the client multiplexes requests to different origins onto a single persistent connection.