they way you see a fork is an intentional split.(controversial). and keeping both side alive..

to me i would call that a controversial fork where a clear defined single direction cannot be established and so extra code is added so the 2 decisions do not rule each other out(blacklisting opposing user agents/flags), which allows both decisions to survive.

a consensual fork is when there is adequate demand and utility that the rules can change without causing a second chain, where the natural consensus mechanism of orphans that would kill off a minority and everyone continues in a single direction of new rules..

in the last year of debate.. the conclusion is that all software implementations should have released a fork code with a consensual activation mechanism. meaning if a high majority desire shows, it activates and then orphans take care of the minority until the minority move over. leading to a single chain.
emphasis high majority desire to move in a single direction

i do not favour controversial forks that add code to force the minority chain to survive. (clams), but that said i also do not favour a certain dev team to veto even releasing code out of fear that everyone would actually show a high desire for it. so abusing the consensus mechanism by not allow users to choose, thus not even giving any new rules a chance.

core fans scream doomsdays of controversial hard forks. but dont realise that core is preventing consensual forks by vetoing a release to ensure the community never get to a healthy majority. thus causing the controversy

so here is the thing.
if cores only worry is a healthy majority.
how about include the hardfork in their softfork code as both require high majority activation parameters. thus when it activates there is no harm because of the consensus mechanism is there to resolve it.