Just did another test:
While beeing in this stituation:
failback on the lan-carp-ip happened to node1
node2 has the IPSec still established
I can continue using the tunnel, if I manually change my gateway from the lan-carp-ip to the second nodes ip address.
So, overall the master node does not reestablish a connection, because the connection is healty - but it is just no longer accessible for lan-clients.
However, the roles themself claimed that fallBACK also has happened for the wan-carp-ip, so it might be an issue on the wan site, where packages of the tunnel communication are still send to the backup-node, even if it does no longe own the wan-carp-ip. This leads to the clusters assumption that the tunnel is healty and no reconnect is required.
But beyond that observation, I could only start to guess, because I'm not familiar to how the whole carp thing works. If it uses MAC-spoofing, there shouldn't be any missrouted packages. If both of the nodes use an own mac-address with the wan-carp-ip it might be the routers mac-address-table / cache that keeps sending packages to the MAC of the backup-role, keeping that tunnel alive and "healthy", which finally surpresses the reconnect of the master role, that would be the one that is accessible by the lan-carp-ip.