If this backward incompatible change will have to be done one day, why not make it only once (by setting an automatic adjustment rule), and why not considering making it now, while it's still easy?
Great, now I only need to relearn C++!
Sorry, no patches coming from me... but I'm glad you are open for it.
But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.
For the jerk with a botnet to succeed with this he would need to either pay lot of transaction fees to include spam transactions in everybody's else blocks, or make the spam blocks himself.
If he's paying, well, miners are getting properly rewarded, the jerk is not a jerk anymore, he's rather an impulsive consumer of miners services. Miners will probably make him pay whatever they need in order to sustain such irrational demand.
Honestly, I don't see this happening.
Now, for him to make it on his own, he would need an immense amount of computing power. Having more than 50% of the network is already a way more dangerous thing than spamming, so let's assume he's not that strong.
Let's say that he has something like 25% of total power, which is already a lot.
He could act in two ways:
Stupid jerk mode: He fills all his blocks with spam, refusing everybody else's transactions. This is stupid because he'd be wasting money, by refusing to accept the transaction fees from others. I suppose people running botnets are not that stupid, but sill, what could the stupid spammer do?
Let's suppose the network is already running with a block size limit of 110% of the average needed. Now, the jerk occupies 25% of the space with garbage, forcing all transactions to be in the remaining 75%. That should be 82,5% of the needed space, so such space will get filled and the block size limit will increase. But how much should it increase? It would stop increasing as long as the 75% space not occupied by the spammer is 110% of what is needed. If I'm not lost in the numbers already, this super-spammer with limited intellect would make the block size limit around 144% (one third + 10%) of what it would need to be.
Anyway, what I want to say is that is that the relative damage he could cause is proportional and limited to the computing power he has, since as soon as all transactions are fitting in the space the spammer does not control, the bock size limit would stop growing. (I probably made some mistakes in the numbers above, but I hope you get the picture)
Having 25% is already a lot, and the relative damage for this stupid-mode is not that great.By picking an arbitrary constant too much higher than the actual needs of the network, we'd probably be giving spammers much more space to spam.
Actually, right now, with this 500Kb limit, a spammer with all this power could probably do much more relative damage, making the network download much more than it would need to.
Now, assuming that the spammer is not that stupid and he accepts paying transactions into his blocks, that greatly decreases the relative harm. Actually, his blocks would contain around 10% of spam only, the rest would be true transactions. He would barely move the block size limit, even with a great computing power.
When we get close to bumping into the block size limitation it will be easy to convince a majority of the network to upgrade-- that's one problem that is obvious and easy to fix.
I hope you're right on that. Nevertheless, consider what I said above: a high constant gives spammers much more opportunity, and risks not creating a sufficient artificial scarcity to incentive mining and thus weakening the network. And a low constant would require frequent backward incompatible changes.