As one of the authors of BIP 9, I have to take a little offence at your assertion that details of its behaviour are inviolate properties of Bitcoin's consensus. BIP 9 is just a tool-- one created a couple years ago to address a specific environment and specific expectations that we had about that environment. From its very first usage it has turned out to be a bit of a let down, and so changes to activation should absolutely be expected. It is absolutely and positively not a integral part of the consensus system and I'd like to ask you to not make this claim again.
[Sorry if that's too blunt, but there are far too many things I wrote as an off the cuff remark years ago that I'm tired of hearing turned around as some kind of unquestionable gospel.]
Those BIPs are marked as "rejected", this isn't.
Rejected status mostly means a proposal has stopped being advanced without being adopted. In a decentralized system there is literally no mechanism to actually "reject" anything in the conventional sense. BIP-8 isn't rejected because its still being maintained. An example of that is that the lockinontimeout was made optional so that BIP-8 could be used in place of BIP-9 which has some specific (minor) technical flaws which are fixed in BIP-8.
I expect that lockinontimeout is a feature that would never be used, and if used only used on an extended timeframe along with a lot of other measures to mitigate the potential for disruption of which everyone is well aware and which few people take particularly lightly. Take a look at the "
modern softfork activation" post for a framework on how that sort of thing might be used if it ever were used. It's specified largely to make it unambiguous that attempts to maliciously move against the neigh-universal will of the users would ultimately be futile, so best for no one to waste their time trying. You shouldn't get worked up about it just because someone added it to a spec, worry about it if there is any specific plan to use lockinontimeout. There isn't currently, nor is there any activation bip that proposes using it or (AFAIK) code for it in any implementation, and I don't expect there to become one in part because its specification will likely eliminate the need to actually use it.
About activation thresholds: One thing we learned from the use of BIP9 is that too high a threshold lowers the hashrate enforcing at activation time compared to prior mechanisms because the high threshold eliminates urgency. But it might put your mind a little at ease to consider that BIP-9 (and by inheritance BIP-8) are designed so that regardless of what the activation percentage is the actual enforcement at activation time can be ~100% -- that is why there is a substantial delay, so there is time for miners to become aware and act. Now there is no guarantee that they will act-- they might be asleep at the switch, or indifferent to causing disruption. But there is similarly no guarantee that even if there were 100% signalling to activate that all of them would enforce. The best we can collectively do is strike a balance between risks.
