Change:
The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses. <del> Note that an ADDRESS_ASSIGN capsule can also indicate that a previously assigned address is no longer assigned.  An ADDRESS_ASSIGN capsule can also be empty. </del> <ins> If an ADDRESS_ASSIGN capsule does not contain an address that was sent previously transmitted in another ADDRESS_ASSIGN capsule, that indicates that the address has been removed.  An ADDRESS_ASSIGN capsule can also be empty, that indicates that all addresses have been removed. </ins> In some deployments of IP proxying in HTTP, an endpoint needs to be assigned an address by its peer before it knows what source address

Discussion:
If an endpoint have received first ADDRESSASSIGN capsule with some address and then receives a subsequent ADDRESSASSIGN capsule the document does not explain the meaning of this. There are several cases: A) Just additional addresses are provided B) Some removal C) Some information are updated D) Combinations I think A) is straight forward and likely to occur. I think B) will happen when some connect-ip requests have been closed, and the need for an address does not any longer exist while a new request has come in. Can C) occur? I guess combinations are possible due to timing. I also think the intention here is to have the new capsule completely replace the old one, and that is also not explicit in the text. I think some clarification on this will be needed to ensure robust implementations.
Fixed by
realize that we need to remember this text from RFC 9000: "Packet and frame diagrams in this document use a custom format. The purpose of this format is to summarize, not define, protocol elements. Prose defines the complete semantics and details of structures." The issue is with at least the adderss assigned capsule: The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses.¶ Assigned Address { Request ID (i), IP Version (8), IP Address (32..128), IP Prefix Length (8), } Figure 4: Assigned Address Format Request ID: If this address assignment is in response to an Address Request (see Section 4.6.2), then this field SHALL contain the value of the corresponding field in the request. Otherwise, this field SHALL be zero.¶ IP Version: IP Version of this address assignment. MUST be either 4 or 6.¶ IP Address: Assigned IP address. If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits. If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits.¶ IP Prefix Length: The number of bits in the IP Address that are used to define the prefix that is being assigned. This MUST be less than or equal to the length of the IP Address field, in bits. If the prefix length is equal to the length of the IP Address, the receiver of this capsule is only allowed to send packets from a single source address.

If the prefix length is less than the length of the IP address, the receiver of this capsule is allowed to send packets from any source address that falls within the prefix.¶ So the actual data format is missing for IP version and IP prefix, and only implicit for IP Address. I would guess they are both unsinged int, but that is not specified. Also the ones that use variable integer encoding from QUIC should be explicit about that. Same corrections needs to be applied to the other capsules.