@Norway, I do accept his arguments that people are lazy, but I think we'll find that as Bitcoin grows and becomes more valuable, this will be much less of a problem (because the people we are talking about here are the miners and node operators).
The solution to this as I see it, is a little benchmark feature for full node operators that bases off of real CPU benchmarking data, and that let's the users configure their block size acceptance settings to within a safe limit of what is actually achievable by their hardware. Combine that with the signaling information about the distribution of EBS/AD, and operators can
a) set their limits to high-enough "fire and forget" values (probably 32MB), and wait until BU solves the next big scaling hurdle (whether it be sharding, subchains, something like NG, etc.)
b) know with good accuracy when their node hardware stats are starting to approach the consensus "minimum" required to keep up with the blockchain
For those who are more paranoid and wish to track the block size increase incrementally (or just need to keep a lot of CPU/memory/disk space headroom on their machines for some reason), they can do so safely too.
There should be more feedback from the node software (client) to the user, informing them of where their node lies on the performance & "how long are my resources going to last" spectrum.
These are mostly questions that can be answered with a bit of math and statistics.
Finally, I believe it will be a liberating experience for node operators and miners to apply their own decision inputs on the blocksize settings and watch how the overall system adjusts. Especially if approached cautiously and conservatively. Let miners raise the block size from 1MB to 1.3MB or whatever is required to improve the service for users. They'll finally have the ability to do this without needing to exchange favors with developers.
I am not opposed to a growth like BIP101, it would be wonderful if it happens. But right now I'd be wary of building that into the software as an automatic mechanism, because it will be used to discredit BU politically, like XT was (on the basis "you don't have enough information about the future" - a valid criticism of this concept imo).
Nothing wrong with adjusting BU defaults in coming releases, preferably using some sort of representative surveys / polls of node operators together with a membership vote.
Default changes usually have to be justified very carefully, and accompanied by more extensive than usual validation activities. Implementing an automatic increase can lead to a false sense of security where one is lulled into thinking "someone must have considered this and determined it to be alright", and consequently skipping a more extensive system revalidation.
---
I made a similar post (maybe a little more circumspect) on Reddit in response to the "Make the default mirror BIP101 and I'll support BU" thread that someone raised
