INCR transfer (X11)
The ICCCM's way of delivering a selection too big for a single property: in chunks, with a handshake per chunk and just as many opportunities for something to go wrong.
When a program requests an X selection, the owner puts the answer in a property on the requestor's window. Properties travel as X requests, and in the classic protocol a request was capped at 256 KB; a whole document on the clipboard would not fit. The ICCCM solves this with the type INCR: instead of data, the owner writes a number, a lower bound on how many bytes are coming, and the requestor understands that more is on the way.
Then the dance begins. The requestor deletes the property, the owner writes the first chunk, the requestor reads it and deletes it, the owner waits for the PropertyNotify about the deletion before writing the next chunk, and an empty chunk marks the end. Both sides have to listen for property events in the middle of a transfer, and both need a timeout in case the other party dies halfway through. It is a piece of protocol many clients implement sloppily or not at all, which explains the classic bug where a large paste comes out empty while a small one works. BIG-REQUESTS raised the ceiling, but INCR remains because the limit never fully went away.