A contentious hardfork (where some portion of the network doesn't agree to modify their consensus rules) is effectively a doomsday scenario, there's no making this safe or making tools which allow you to transact on two chains simultaneously with no ill effect.
This almost happened once before, and the miners picked the fork that solved the problem (a fork that would otherwise have lost, mind you).
That does not reflect current understanding of how BIP50 operated.
The chain abandoned by human intervention was actually the correct one, the decision was made just because a majority of the networks nodes were using buggy software that would have had to have been updated very quickly. Nodes running 0.7 or earlier software could randomly fail out of consensus (with 0.8, or even just with other nodes running the same version) depending on their own environmental influences.
It's a little out to argument if fixing the implementation was a hard fork or not, but BIP50 is not an applicable example for gaining knowledge about how the network might operate under intentionally changed operating conditions.
How long do you think it would take for bitcoin clients to appear that would ensure that your transaction is broadcast to both forks so that anyone seeing only one chain would see your transaction?
There is no scenario in which two networks can continue to happily operate in unison.
The two chains of differing consensus rules will fall out of synchronization. Inevitably due to a single transaction not confirming, being mutated between the chains changing the TXID, or someone spending a coinbase output, transactions on one side will become invalid where they would otherwise be valid on the other.
Rebroadcasting your transaction doesn't mean anything if it literally cant't exist in both chains, no wallet vendor will bother doing this for the extreme amount of development time required to make it work functionally, and the high amount of user confusion it would cause.
Clients on one side (or both) will ban their peers for not following consensus rules. This is part of a long list of denial of service attack prevention measures which include sending invalid blocks and wasting validation time on something that can never be accepted. Nodes that disable this rule may find that they reorganize onto different chains and flip flop between them
If two fictional companies Coinbarse and Bitflinux decide they will follow alternate chains, then there is an opportunity for every Bitcoin owner with an account on each to double their money. Simply sell your BTC twice for USD on each chain and you've got double the USD you would otherwise, the markets clearly couldn't survive this sort of behavior one way or the other.
The worst people using bitcoin generally rely heavily on irreversibility, and the best people nearly always have some way to re-do any reversed transaction (rebroadcast is built into the standard client)
That does not accurately portray the behavior of the system, and I'm not sure how that couples with "worse" people. If somebody pays you with a mature coinbase output which is reorganized out of the chain, then you are stuck without your money no recourse. If someone pays you and an alternate payment included in a different block, then you are stuck without your money no recourse. The vast majority of users do not use wallets which rebroadcast transactions, and in almost all scenarios where payments could be reversed there is a high probability that they could also become invalidated as well.
The simple answer is just that if you don't want dangerous and undefined things like this happening, don't go along with the belief that 75% of the mining hashrate is "consensus". Work towards solutions which don't actively destroy the ecosystem, and have complete agreement on their implementation and execution.
