But then what happens if a lot of xt miners are also producing blocks to the point that the forked chain had enough halshpower to survive?
That's the point.
You can't REALLY know how much power is in each side BEFORE the fork, only AFTER the fork.
What will happen if we get that 75% of blocks were mined with those bits setted but, in reality, the hashpower is 49.3% and 50.7%. Goodbye Bitcoin.
This fork COULD BE a mess, maybe not, but could be in the scenario that I'm describing. This is REALLY necessary?, it is too much risk mate. We should stay with Bitcoin Core and make a new version of it, not building ANOTHER client to fork the blockchain.
In fact not.
If the network split in half the hashpower over the two branches, the confirmation times double for both.
The transactions would be the same (apart for the new coins mined) on both chains.
The problem would be for the 1MB, because if the mean blocksize was 500KB before the fork, it now would be > 1 MB after. For both.
Larger the mean block size before the fork, worse the effect on the 1MB branch.
Now, one chain would be able to confirm all transactions anyway. The other would not.
Immediately there would be a backlog of transactions in the 1MB branch but not in the 8 MB branch.
This would last about 4 weeks before resetting the difficulty.
This is where a good dynamic scheme, implemented in Core to the XT fork schedule, could provide a solution.
Your scenario would play out oppositely, the 8 MB chain could end up overwhelmed with all sorts of attacks, while the dynamically sized chain would scale above 8 MB to handle it.