Yes, I was aware that a softfork only proposed in a minority client would not affect any other implementation. If for example Knots set a threshold of 5% and Ocean magically tripled its mining participation and was able to lock it in, then they would simply enforce rules no other miners would enforce (if they still remain backwards compatible), and thus miss miner income or risk to fork away if they try to enforce the rules on blocks found by other miners.
This BIP treat certain transaction as invalid (rather than non-standard). So backward compatibility should be impossible, since miner and node who support this BIP would treat certain block/TX as invalid and cause chain split.
Having a "minimum threshold" in such a scenario would perhaps make sense.
In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days. Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.
In general, if you have 10% network support, and you reject the majority chain, then it takes a week to have coinbase transactions with 100 confirmations, which could be moved anywhere else.
--snip--
FWIW, if the minority decide to perform hard fork, they could add EDA (emergency difficulty adjustment) or something similar to attempt solving that issue.
