Its a bit strange that the small blockists are so opposed to BIP100 consider that BIP100 would allow the miners to decrease the blocksize if they determined this to be to their advantage.
Jeff Garzik, originator of BIP100, has himself stated it is unlikely (read:impossible) that BIP100 gets adopted so there's really no point debating it.
We are opposed to it because we understand the game theory dynamics of Bitcoin which quite obviously you don't
Fortunately it is not up to the Core developers what proposal the economic majority will adopt. If Jeff Garzik does not implement BIP100 then other people can implement this so far hypothetical BIP100 instead. I would not be surprised if Core took to long to implement this, that the miners themselves might even release and support this implementation.
For the millionth time, the miners don't decide what code gets run, the nodes do.
Core doesn't bother with BIP100 as it is clear its hasn't gotten near consensus acceptance from relevant actors and so it should be considered dead.
Cores idea of developer consensus is laughable they just censor and ban anyone who does not agree with them and call that consensus. True Bitcoin consensus is superior, firstly reflected by proof of work and then by the full nodes.
While your idea that miners can fork the chain with 51% (they can do that with any percentage, actually) is
technically correct, it's barely applicable in the real world.
Miners are among those entities losing the most in case of disruptions. They are incentivized to be as conservative as possible, which means that, when acting rationally, they will strive to get near-100% consensus on every important change. That's the reason they have rejected BIP101. That's the reason they are only passively voting for BIP100.
My expectation is that within the next 6-12 months there will be an acceptable schedule like 30% yearly increase for a couple years. This time limit will ensure that we're conservative enough so as not to cause any disruptions.
My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.
I agree that miners would not fork unless they thought they had a high degree of consensus, which is why it is highly unlikely in the real world that such a 51% fork would take place, I was just using this example to illustrate a point.
I disagree with the viability of near 100% consensus especially for contentious issues. I think that 70%-100% is sufficient, especially considering that a small minority would be able to enforce their beliefs onto Bitcoin purely by preventing any change.
I would actually support a thirty percent increase per year when implemented.
I would also personally prefer optimizations first, however I do think that if these optimizations are not completed before we need to increase the blocksize then the blocksize should just be increased anyway.
The primary scenario that I would like to avoid is transactions becoming unreliable and much more expensive, as long as that does not happen I would be happy with the situation. Which is why I can also agree to a yearly thirty percent increase. I am not prepared to "trust" Core to implement this however, there should be a limit to our patience. I am not prepared to wait for several years for instance, especially if that means that the scenario I described plays out. Since if that did happen then our "trust" was certainly misplaced and Bitcoin would suffer for it.
