A question on the BIP110 chain and lack of replay protection

[The Hidebehinder]

I didn't pay too much attention to this and considered it a dead project from the start, but after a talk with a few friends last night about what they are planning and what they are, I arrived at some conclusions, be they right or wrong, so just to get this right and not live with a misconception

• Luke Dashjr intentionally faked the target difficulty at the start, knowingly, so their chain could catch up with Bitcoin by pumping two weeks of blocks in 3-4 days, and probably 7 days for the next one, as he has some spare gear he hasn't yet forced onto the network, so he can claim his chain is gaining supporters.
• He and BM forced the smaller block size to make the chain look full of transactions when the capacity is actually down 70%.
• The replay protection was not about him thinking his coin is Bitcoin, but to allow transactions to be picked up by their chain too and not look empty.

If I'm mistaken on the last in some technical thing, just correct me, and there's no need for the rest.

My question is: what happens if I create a valid transaction on the Bitcoin chain but invalid on BIP110, and I send, let's say, X satoshi of dust to 100 addresses of exchanges, casinos, etc. that I know thy auto sweep their balances and consolidate inputs, do those consolidate inputs automatically become invalid on the BIP chain?
Would this kind of "poisoning" start to I don't know how to say this invalidate all further generated transactions from an exchange and forking this completely if done by hundreds of users?

Not that I'm planning to do it, but I was a bit annoyed to check their mempool and see 20 pending transactions to my wallet on their chain.

[Antidote47k]

I think the “poisoning” scenario is plausible though it might not automatically break the chain. If the transaction is valid on only the legacy chain and invalid on the BIP-110 chain, that UTXO would only exist on the legacy chain. If the exchange  later includes that UTXO as part of consolidation transaction, the transaction should also be invalid on the BIP-110  chain cause one of its input doesn’t exist in its UTXO set.

The real question now is what the exchange does with such transactions. If it keeps including those legacy only UTXO into subsequent consolidation transactions, this might potentially cause repeated failures on the BIP-110 side but that shouldn’t necessarily fork or break the exchange, if the exchange identifies the UTXO and exclude it from transactions meant for the BIP-110 chain, it’s other UTXOs should technically still be spendable there.
The only thing I’m wondering about is wether the exchange’s automated sweeping can be able to identify that now there are two different UTXO sets after the split.