Hey I'd be fine with a 5 MB block size limit, and some percentage increase every year afterward. I think 20 MB would probably be better, but that's far less important than putting in place some dynamic hard limit, ANY dynamic hard limit, that steadily increases, year by year, so that we never have to do a hard fork again to change the limit.
If this limit increases faster than than the interest in spending money for transactions then it will kill Bitcoin. It has to cost quite a lot to do transactions. If it doesn't there will be too little interest in mining, and a 50% attack will be cheap. Currently the interest is going down, so there is a fairly large chance that any changes will do more harm than good. What's certain is that if there is a fork then all kinds of problems and scams will follow, and the Bitcoin critics will have a field day in the media.
I'd disagree that it has to cost a lot to do transactions.
But I would like to NEVER have to do a hard fork again on this issue. Uncontrolled increases which are insensitive for the need for transactions don't provide such a guarantee. They will be too large or too small. We know that we can not accurately guess the future of Bitcoin.
So from this perspective what is needed is a BIP to track the # of transactions (or another metric that corresponds to block size) and use it to set the Max Block Size. Then it could adjust in a similar way to difficulty. Hard minimum-maximum may be set (so that there is no pernicious incentive for empty block attacks), and there can also be a hard maximum-maximum set (so that spamming attacks can't spiral out of control before some intervention is taken).
We all agree "don't fix it if it isn't broken". (though intelligent people may disagree on whether it is broken)
We all should also agree "don't fix it if you don't know how". (there is currently broad dissent on the how)
This would give us a "how".