Technical problems in deployment of segwit parallely on bit 4 Recently(as of May 24, 2017) segwit2mb HF has been proposed. A core developer has reported that another deployment of segwit via bip 109  on bit 4 would require code duplication. 
Although the above link comes with some justification, I fail to understand the reasoning. 

What will be consequences if we simply change the block threshold(95% of 2016) to 80% of 2016 and give it out as a new binary? Is there a network split risk?
If the miners activate segwit by signaling readiness for segwit on bit 4 (further called segwit4) immediately, all nodes that follow the current activation procedure (signaling on bit 1) would ignore this activation. Regular segwit enabled nodes would interpret transactions and blocks created with segwit according to the old rules. After segwit4 activated they would still consider segwit transactions to be not allowed yet, and thus with the first segwit4 transaction appearing on the network, ban the relaying nodes for forwarding invalid transactions. At this point, this would split the network between miners and all nodes that are segwit1-enabled.

Activating two different versions of segwit on the network would trigger untested interactions between nodes, as several parts of the relay code logic is dependend on the signaling bit. Only interactions between segwit-enabled and segwit-unaware nodes were tested extensively, so one should expect new code and new test cases to be necessary to avoid a netsplit with segwit1-enabled nodes.

This would perhaps not matter terribly much, since according to Garzik on Twitter the blocksize increase would be activated at the same time as SegWit4, so any old type nodes would be hard forked off the network anyway as blocks created by the new chain would appear invalid to them. 

Update: Apparently, there are at least three opinions out there about the activation order of segwit, and the hardfork since Consensus, so I'm waiting what it'll be.