Three-way handshake
1. step
The client begins the three-way handshake by sending a segment with the synchronize sequence number (SYN) control flag set, which indicates an initial value in the sequence number field. This value is known as the initial sequence number (ISN). The ISN is randomly chosen and is increased by one for each byte of data sent from the client to the server.
ACK : not set | SYN : set
2. step
The server must acknowledge the receipt of the SYN segment, so it sends a segment back with the ACK flag set. The client recognizes this as an acknowledgement that the server received the SYN from the client.
The value of the ACK number field is the ISN + 1.
The server also must initiate a response to the client. To achieve that the server uses the SYN flag in the same way that the client did. (So it is one segment)
ACK : set | SYN : set
3. step
The client responds with a segment containing ACK that is the response to the SYN sent by the server. There is no user data in this segment. The ACK field contains one more than the ISN received from the server.
After both sessions are established between client and server, all segments exchanged will have the ACK flag set.
ACK : set | SYN : not set
(Note: the whole conversation between the client and the server is actually two one-way sessions)
I think the part you are missing is that the acknowledgement number is the number of the data expected next. A segment with an ACK says I acknowledge everything before this acknowledgement number, and the next data I expect will start with this acknowledgement number as its sequence number.
In the first diagram, there is no acknowledgement number in the first segment (SYN) because the sender does not yet know what sequence number the receiver will use to start. The next segment (SYN and ACK) has both a sequence number, and the acknowledgement number is the sequence number it received plus one because that is what it expects next (any data next received would start with that sequence number). The ACK flag is set, so it is acknowledging receipt of everything prior to the acknowledgement number, and setting the expectation of what the next sequence number of data it receives should be. The third segment (ACK) also has the ACK flag is set, so it is also acknowledging receipt of everything prior to the acknowledgement number, and setting the expectation of what the next sequence number of data it receives should be.
If you understand that, then the second diagram also makes sense. Remember that almost every segment after the initial handshake will carry both data and have the ACK flag set. The FIN segment could be carrying data, too; it is simply telling the other side that it is done sending, but the other side could continue to send data until it is done. Apparently, the other side is also done, replying with a FIN, but also an ACK and the acknowledgement number needs to be X + 1 to indicate that it acknowledges everything less than that, and any data received next would need to start at X + 1.
In the third diagram, the two segments that have the sequence number of 1400 are correct because neither shows to be carrying any data. It is the data that determines the sequence number, and it is what is next expected in the acknowledgement number.
Best Answer
Identical sequence numbers in different connections (=sockets) are not a problem. Each socket tracks its own sequence numbers. At any point in time, a socket is unambiguously defined by the sourceIP:sourcePort:destinationIP:destinationPort tuple.
To ensure that a previously used source port isn't reused while data may still be 'in flight', the port is blocked (with a FIN-WAIT state) until the closing has been confirmed by the remote host (or it is eventually timed out).
For each connection, each segment's position in the potentially infinite data stream is defined by its segment number. That would only pose a problem if the pipe grows so large that it wraps the 32-bit field - you'd need to have 4 GB in flight for that, which only becomes an issue for an interplanetary network. Currently, TCP's window scale option only allows a size of up to ~1 GB.