@Luke
> They can still slow it down.
Absolutely. However I think that the option of permanent failure is important. It certainly would be ideal to ensure that enough bitcoin users support the upgrade *before* releasing it, however realistically this can never be more than an estimate, and estimates can sometimes be wildly wrong. It would be unfortunate if miners had a substantially different estimate of user support than the people putting in the work to release bitcoin upgrades. Even if upgrades are never released before it becomes clear that a large supermajority of users want the upgrade, if miners don't agree with the estimate a harmful chain split could occur. And I agree with Eric that the goal here is to prevent a chain split during an upgrade when possible. This includes permanent failure of an upgrade when there is unexpectedly large miner opposition.
This of course does not prevent a UASF-style deployment to be done after an initial failure to deploy occurs. My proposal is essentially a mechanism to improve upon the speedy-trial idea, allowing for even speedier releases (than speedy trial) without adding additional risk of undesired chain splits.
> [BIP8] already has the trinary state you seem to be describing
It sounds like you're saying the trinary state of BIP8 is A. Follow the longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded chain. I agree. However the trinary state in my proposal is materially different - it is the signaling itself that is trinary, not just which chain is being followed. This allows others to know and make programmatic decisions (in software) based on that signaling. I'm sure you can agree that does not exist in BIP8.
> No additional bit is needed, as softforks are coordinated between users, NOT miners
And yet there is miner involvement, as you rightly pointed out. Miners are needed to set the nVersion in the header. So when you say "no additional bit is needed", could you please be clearer as to what you mean? Do you mean that signaling of opposition in a block can be done without any "additional bit"? Or are you just saying that it is redundant to consider what miners might be opposing an upgrade?
@Jorge
> If different users want different incompatible things... there's no way to avoid the split
I agree. This happened with bcash, and that's fine. It was painful, but there were a significant amount of users that disagreed, and they have the chain they want now.
But we generally all want to avoid a chain split when possible. Because chain splits have a cost, and that cost can be high, its likely that many users would rather choose the chain with the most support rather than choosing the chain with their preferred rules.
However, the question here is: how do we estimate what fraction of users wants which rules? We don't have a divining rod to determine with certainty what users want. We can only make polls of various levels of inaccuracy. The methods bitcoin has been using is community discussion and social consensus estimation as well as miner signaling during the actual deployment period.
Neither of these are perfect, but they are both reasonable enough mechanisms. However, because both of these mechanisms are very rough estimates of user sentiment, we need to consider the possibility that sometimes the estimate may be substantially inaccurate when we design deployment procedures. This inaccuracy is why we need multiple barriers in place for an upgrade, and why we need to have higher thresholds of success (require larger supermajorities in both consensus and miner signaling).
Developers obviously care about bitcoin and have an incentive (personal and probably financial) to do it right. And miners have both an incentive to keep the system healthy, as well as an incentive to mine on the chain that the economic majority of users is using. But measuring the consensus of the bitcoin community can be extraordinarily difficult to do with consistent accuracy, and so I think miner signaling as it has been used as a second barrier to entry for an upgrade is quite appropriate.