However the problems happen when 51% of the miners decide to start mining blocks larger than 1MB and 51% of the nodes supported blocks up to 2MB, then the blockchain would fork, specifically a hard fork. There would then be two blockchains. One blockchain would include blocks larger than 1MB while the other would not. The blockchain with larger blocks would be rejected by nodes that don't support larger blocks. If the blockchain with the smaller blocks happened to become longer than the blockchain with larger blocks, it could orphan that entire other blockchain. However, if the other larger block blockchain was longer than the smaller block one, then two blockchains would continue to persist until everyone agreed to use one or the other blockchain.
....
Because of the issues that can be caused by competing blockchains, the block size limit will only change with consensus. It only happens if nearly all of the miners and users agree to support those larger blocks and agree to upgrade to code that supports those blocks. Without consensus we would have competing blockchains which could be disastrous.
Are you saying if miners switch to Bitcoin classic (once available) or change the header file in their nodes we might end up with two chains?
If you did this today, your 2MB blocks would be rejected. Unless they run their mining operations hoping others switch their nodes to higher limit so that they can accept larger blocks, confirming each other.
They can decide to do just that, but the issue is of source control. When you are a miner with X number of nodes, you want consistency in your setup.
You want fast, reliable setup. Last thing you want is to be maintaining core code.
You don't want to solve orphaned or rejected blocks. Waste of time and money.