- snip -
But, if we put aside the silly notion of everyone agreeing, and get pedantic about it, it is still a hard fork because bitcoin is software. Software does what it does, it doesn't care what anyone thinks. Even if you agree to the change, it is still a hard fork because any old software running will enforce the rules it knows, not the rules you agree to. So to prevent a hard fork requires more than merely that everyone agree, it also requires that everyone replace their software, and then never allow the old code to run any more.
The old software will never be compatible with the new software. We could even get philosophical and say that the hard fork exists once the new software is created, even if the length of one of the tines is zero (that is, even if no one actually runs the old software).
We are now in agreement on the matter. At this point the only debate is on the definition of the term "fork". If we are discussing a software fork (such as the Red Hat fork that created Fedora), then I'd agree that a change that increases the limit is a "fork" regardless of how many people use it. On the other hand, if we are talking about a blockchain fork (such as happened between the 0.8.0 Bitcoin-Qt and earlier versions), then I'd say that if you could get unanimous consent, there would not be a "fork".
That isn't so much a debate as a decision. The term has multiple meanings, and we are broadly in agreement on the consequences for each of the relevant meanings. I say broadly only because it still takes more than consent to swap out all of the software; mere agreement won't prevent the (chain) fork, action is also necessary.
But discussions of universal consent are pointless, except as an exercise in rhetoric, since at least one of us is already on record as non-consenting.