There's no way to create a fork on those transactions, since the majority of the network needs to receive them in the next round at most, to confirm them. Think of lockers as a pre-validation step, gatekeeper to the system if you will. Since those transactions were not confirmed by a majority of the network, that means that those transactions will never be accepted, and everyone the applied them will undo them.
Between the time a transaction is signed by a locker and confirmed by the network, it's essentially pending. We expect running a full node to be something that only servers with decent processing power and good internet should do, so delays are rare. The latency between almost any pair of servers with decent internet in the world is less than 300ms. Even if delays happen between some pairs of nodes, there would have to be a global internet problem in order for a majority of the network to have these issues.
In essence, we want to optimize the system as much as possible for the average case, while still being robust for any worse case.
I understand that, but what about the round itself? Surely there's a case where a given round can be submitted with a separate set of transactions, leading to a fork?
Btw, worldwide network propagation using gossip is on average 15s, that's why ETH's block time is around there.