Change:
type selected by the server (resumption or full handshake) as clients will most likely discard any additional tickets. <del> When a resumption is performed, and the requested resumption_count is zero, the client is requesting ticket reuse.  If the presented ticket is valid for additional resumptions (only possible when the server supports reuse), it SHOULD return no tickets.  Otherwise, when either the server does not support reuse, or the ticket is expiring, and needs to be replaced (e.g. reissued under a fresh session-ticket encryption key) the server SHOULD return one ticket. </del> <ins> When the client presents a ticket for resumption, but the requested resumption_count is zero and the new_session_count is non-zero, the client is requesting ticket reuse (despite section C.4 of RFC8446). If the presented ticket is valid for additional resumptions (only possible when the server supports reuse), it SHOULD return no tickets.  Otherwise, when either the server does not support reuse, or the ticket is expiring, and needs to be replaced (e.g. reissued under a fresh session-ticket encryption key) the server SHOULD return one ticket. </ins> Servers SHOULD additionally place a limit on the number of tickets <del> they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested. </del> <ins> they are willing to send (whether for full handshakes or resumptions), to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested. </ins> A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.new_session_count indicates the number of <del> tickets the server expects to send to the client. If the extension is echoed, the TicketRequestContents.resumption_count can be set to a non-zero value to indicate that the server supports ticket reuse, otherwise (i.e. zero) the server does not support ticket reuse.  Ticket reuse has privacy implications and should be used with care or not at all, see the security considerations section. </del> <ins> tickets the server expects to send to the client.  If the extension is echoed, the TicketRequestContents.resumption_count can be set to a non-zero value to indicate that the server supports ticket reuse, otherwise (i.e. zero) the server does not support ticket reuse. Ticket reuse has privacy implications and should be used with care or not at all, see the security considerations section and section C.4 of RFC8446. </ins> Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection

Discussion:
This improves both happy eyeballs and ticket reuse.
I am significantly skeptical re complexity. The server looks at one counter when resuming and the other when doing a full handshake. Where's the complexity? I am sorry to say that to me personally, the complexity objection sounds rather like reluctance to reconsider the design than a response on the merit.
I still don't think that the additional count is warranted. The rationale here is reasonable, and does provide a degree of justification for the change, but I would prefer not to take on the additional complexity.Thanks for making the updatesThanks for putting this down in writing! I think a separate counter is fine given the rationale, but I disagree with all text on re-use. I think that should happen elsewhere. So, requesting changes for now, though if the WG decides to address ticket re-use here then we will revisit!