That'll make a new slot by looking for a recent/future non-overflowed xl_running_xacts record to set as restart_lsn. Every xact that starts _after_ that xl_running_xacts record will be decoded and replayed to the client in its entirety. Every xact started before that xl_running_xacts record, i.e. listed as running in the record, will not be replayed to the client at all, whether it commits or rolls back, even though the commit will be after the slot creation lsn.
I have also tried to calculate last origin LSN for this node and explicitly specify it in START_REPLICATION.
That will have no effect because of the logic you pointed out around confirmed_flush_lsn.
Dropping and re-creating the slot is the wrong thing to do if you want to maintain consistency. Just advance it over the changes you already saw from the other node. Read BDR's catchup mode code.