Change:
in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the <del> connection with the H3_SETTINGS_ERROR error code.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. </del> <ins> connection with the H3_SETTINGS_ERROR error code. The client MUST NOT send a WebTransport request until it has received the setting indicating WebTransport support from the server. Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of WebTransport extension that is different from the one used by the server. </ins> If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating <del> QUIC DATAGRAM extension SHALL result in a H3_SETTINGS_ERROR error. </del> <ins> HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error. </ins> HTTP3 requires client's "initial_max_bidi_streams" transport parameter to be set to zero.  Existing implementation might enforce

Discussion:
Requires the server to defer the processing of any incoming WebTransport sessions until the relevant settings have been received from the client. This makes versioning WebTransport extension possible.
How necessary is to wait for SETTINGSENABLEWEBTRANSPORT from the client? If we are a server, and we receive a request with set to , this seems like a pretty solid indication of support. From the current language in the draft, though, the server has to pause the processing of the request in question until the SETTINGS are there (which is really annoying to implement). One counterpoint I can see is that we could use settings to negotiate a specific version of WebTransport over HTTP/3, and in that case we do need to wait for settings from both parties.
I really do not like the idea of delaying the processing of requests on the server side, as it seems bug/attack prone. Given the client has to initiate the webtransport session, and there's no guarantee the client's SETTINGs will arrive before the servers(without something like ALPS), why not only have the server send the setting? For example, websockets in H2 only requires a setting from server to client.
One tricky thing here is that whatever we do here, it has to also work with the H3_DATAGRAM setting.
I'd suggest adding some requirements like: 1) The server MUST indicate support for both WebTransport and H3 datagram, or the connection MUST be closed. 2) The server MUST assume that if the client uses protocol "webtransport", that it supports both WebTransport and H3 datagram, and sending the SETTING is optional. But you make a good point that this could crop up in CONNECT-UDP and a few other uses of H3-Datagram. If the client is always responsible for initiating the datagram flow(s), then the SETTING for h3-datagram only needs to be sent server to client.
Discussed at the May 2021 interim. The agreement in the room seemed to be that this is unavoidable if we want to use SETTINGS for determining the version of WebTransport to use by the server.