ext_image_copy_capture_session_v1 capture guarantee is too strong and too weak

The protocol explicitly calls out a situation where the compositor must send a frame as soon as possible:

Unless this is the first successful captured frame performed in this session, the compositor may wait an indefinite amount of time for the source content to change before performing the copy.

However, this makes it sound like there are no other situations where the compositor must send a frame as soon as possible. Consider the following examples:

• The source was resized and the capture failed. In this case the compositor should immediately send a frame on the following capture since otherwise the client's last successful capture will have a different size from the source.
• It is not impossible for the copy to take so long that the client misses the next frame. For example, if a client captures a high-refresh-rate output with a shm buffer, the compositor will likely perform the copy to the shm buffer asynchronously in order to not block. This might cause the client to get stuck on an outdated frame if the output suddenly stops drawing after the client missed a frame.

A sensible compositor will already handle both of these situations by forcing a new frame if the client would otherwise have an outdated buffer. But having the protocol call out only one of these situations is confusing. Maybe rewording this as follows would be helpful:

Unless the source contents have changed since the previous capture, etc. etc.