Duas conexões seriam feitas. O TCP não está ciente do estado dessa maneira - nenhuma conexão teria qualquer conceito da outra conexão.
Por exemplo:
Connection 1:
192.168.1.5 sends SYN to 192.168.1.6 on port 80.
Connection 2:
192.168.1.6 sends SYN to 192.168.1.5 on port 80.
Para que isso continue, ambos precisariam de um serviço de escuta na porta 80, então cada um teria algo escutando no TCP para a porta 80 e esse serviço receberia o SYN e responderia com um SYN-ACK:
Connection 1:
192.167.1.6 responds with SYN-ACK to 192.168.1.5 on port 80
Connection 2:
192.167.1.5 responds with SYN-ACK to 192.168.1.6 on port 80
Tenha em mente que esses serviços de escuta estão em máquinas opostas - não há como saber que o outro também recebeu um SYN, então não há razão para eles não enviarem um SYN-ACK.
Como o protocolo TCP determina, uma vez que o lado de origem recebe o SYN-ACK, ele responderá:
Connection 1:
192.168.1.5 sends ACK to 192.168.1.6 on port 80.
Connection 2:
192.168.1.6 sends ACK to 192.168.1.5 on port 80.
Agora você tem duas conexões independentes com handshakes TCP completos. Como mencionado nos comentários de SvW: se isso é ruim, cabe a qualquer aplicativo iniciar as conexões para determinar se esse estado estava presente e descobrir qual conexão quebrar - essa parte não é o trabalho do TCP.