You're conflating a lot of things here. Racing a fraudulent transaction to have a legitimate one confirm faster is not a double spend, like at all. Up until the moment one of the transactions confirms, no funds have changed hands. What you're also conflating is the fact that the hash collision has no influence on transacting funds in the first place. The DCI report recently released their vulnerability exploiting code which demonstrated, that in order to actually use colliding transaction hashes to create fraudulent transactions, the fraudulent party would have to have access to the seed at which point the whole thing becomes moot anyway. Adding to all this, the hashing function has long since been replaced, further compounding the moot-icity.

Is not a race a way to delay individual transactions and essentially an DOS for targeted members of the network?

For the double spend to occur, you would need access to the seed ( private key) which the victims had and are trying to outrun the attacker in the case you were describing.

>For the double spend to occur, you would need access to the seed ( private key) which the victims had and are trying to outrun the attacker in the case you were describing.

So it works a bit like replace-by-fee on bitcoin? There is no mining on IOTA so what is the possible time frame? do you have more detailed technical information how this works? Thanks

New transactions are selected randomly to be verified. So in case the attackers transaction is still not confirmed there is a chance to outspend him by having the private keys. I find this useful in understanding the confirmation/consensus mechanism. https://forum.iota.org/t/iota-consensus-masterclass/1193

You know how hash collisions work and why it is important to have an hashing algorithm for which it is hard to enforce collisions.

It is so you do not need to know the private key. So that you can forge fraudulent transactions without knowing the private key.

Still not a double spend.