if nodes avoided consensus and put up the ban node barricade to cause an intentional split then,
if you are going to do that, then certainly change the mining algo.
especially if the split you are on is a low hashrate. because by going it alone is not just exposed attack. but also causes the nodes to be waiting alot longer for genuine blocks to be produced due to high difficulty vs low hashrate.

---

due to intentionally banning nodes there would be 2 sets of data with different chains. because the nodes are no longer cooperating/connecting to eachother to form consensus and orphan the wrong/undesirable blocks.

if you have changed the mining algo and now you have your own altcoin, name it clams 2.0 or another random name but its no longer bitcoin

---

if however you stuck to the same algo's and wanted to play out pool attack scenarios of what could happen if an opposing pool hopped over to your altcoin... then here goes

opposition with low hashrate (under 50% of your network):
the opposition either has to follow the rules of your altcoin to get accepted into that chain to avoid rejects/orphans means the only attack vector that has consequence is 'empty blocks' to cause a bottleneck of transactions left waiting in mempool, and not be subject to reject/orphan risk.
else not following the rules they would get rejected and the nodes just wait for the next genuine rule following block. (no drama)

medium hashrate over 50%:
same as before but this time there are more empty blocks,

else not following the rules same as before but this time they also may be able to build a heritage of rejects if they manage to be next inline for the following block to. resurrecting their reject now as a parent to then add another block ontop as a child, where both simply get rejected (this is then buzzworded 'orphan')  (no drama)

high hashrate:
same as before but this time there are even more empty blocks,

else not following the rules same as before but this time they also may be able to build a deeper heritage of rejects if they manage to be next inline for the following block and the following block after that. resurrecting the first reject now as a grandparent to then add second reject ontop as a parent and the newest block as the child, where they simply get rejected (this is then buzzworded 'orphan chain') (no drama)

---

rule following, no reject 'empty block' attack vector.
   if able to be persistent(many weeks) and have high enough hash power.. can also cause the difficulty to rise so that the ethical pool has less chances of having blocks with transactions included.
rule breaking, attack vector.
   if able to be persistent and have high enough hash power.. can also cause nodes to just get spammed with rejects while nodes wait for genuine blocks

now take note of my very first sentence.
there is only 2 chains if the nodes intentionally ban opposing nodes.
just having bad data does not cause long term permanent chains. because eventually it will orphan/reject the bad data out, where the low minority rejecting the high majority(on the one chain) simply end up being spammed with rejects/orphans while waiting for genuine blocks

---

what i have said in this post is about POOLS hopping over.

however if the opposing NODES hopped over and took over the altcoin chain by a dominant majority amount of nodes (sybil attack) this would allow them to accept the rejected data and build on the chain as acceptable where by the rules change.. leaving the minority stalled and unsynced