It is highly unlikely that a host will send the same sequence number twice in a row to open a connection. Remember that this is a 32-bit random number, and the RFC specifies that the number should only repeat every four and a half hours or so. By using a random sequence number this way, a delayed SYN can be discovered.
What you really have is a four-way handshake, but it is done in three segments. Each side sends its sequence number, and each side acknowledges the sequence number from the other side, which lets the other side verify that the sequence number it sent is correctly received by the other side. See RFC 793, Transmission Control Protocol:
The synchronization requires each side to send it's own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side. Each side must also receive the other side's
initial sequence number and send a confirming acknowledgment.
1) A --> B SYN my sequence number is X
2) A <-- B ACK your sequence number is X
3) A <-- B SYN my sequence number is Y
4) A --> B ACK your sequence number is Y
Because steps 2 and 3 can be combined in a single message this is
called the three way (or three message) handshake.
A three way handshake is necessary because sequence numbers are not
tied to a global clock in the network, and TCPs may have different
mechanisms for picking the ISN's. The receiver of the first SYN has no
way of knowing whether the segment was an old delayed one or not,
unless it remembers the last sequence number used on the connection
(which is not always possible), and so it must ask the sender to
verify this SYN. The three way handshake and the advantages of a
clock-driven scheme are discussed in
[3].
For example, if Host A sends a SYN to Host B, but it somehow gets delayed and Host A again sends the SYN to Host B, or the SYN gets somehow duplicated on the network, Host B uses its ACK to verify with Host A that the sequence number is correct. Host A would see that it is not.