from my knowledge, seq and ack_seq are processed by tcp stack independently.
when a packet arrives with a inconsistent ack_seq number
if: 1) the ack_seq number is obsolete(smaller than expected), e.g, a dup ACK, this packet doesn't fail the validity check, so if it has data field, and the seq number is correct, the data is still accepted due to the independence of seq and ack_seq processing.
2) if the ack_seq number is ahead (larger than expected), then it fails validity check, this packet will not be delivered to tcp stack. So even if the processing between seq and ack_seq is independent, there is a invalidity issue before the processing. And the packet will not be processed by TCP stack.
( Note: there are some sequence number inconsistency in the tcp connection between 126.96.36.199 and 188.8.131.52, I'm not going to talk about the inconsistency problem, it is another topic)
However, from the graph above, in the 1013-th packet, 184.108.40.206 sends a FIN/ACK packet, it has an ack_seq 2086 which is ahead of the sequence number(1) of the 1011-th packet. In theory, the FIN/ACK fails the validity check and should not be accepted/processed by the tcp stack. But the host 220.127.116.11 sends back a tcp ACK(the 1014-th packet). Why?
And besides, although the 1014-th ACK packet has wrong seq number(which is 2, but expected to be 2086), it has a correct ack_seq number and doesn't fail the validity check. And according to the principle of independent processing, it acknowledged the 1013-th FIN/ACK packet correctly. Why 18.104.22.168 still retransmit the FIN/ACK?