3) Let me put it another way, I've read that both Gavin and yourself are favorable to a dynamic limit on the block size. In your view, what is missing from this proposal, or what variables should be adjusted, to get the rules to a place where you and other Core developers would seriously consider it?

I'm not clear on what problem(s) you're trying to solve.

If you want blocks to be at least 60% full, then just specify a simple rule like "maximum block size is 1.0/0.6 = 1.666 times the average block size over the last N blocks (applied at every block or every 2016 blocks or whatever, details don't really matter)".

If you want an upper limit on growth, then just implement a simple rule like "Absolute maximum block size is 1 megabyte in 2016, 3.45 megabytes in 2017, and increases by a maximum of 3.45 times every year."

If you want me to take your proposal seriously, you need to justify why 60% full is a good answer (and why we need a centralized decision on how full blocks "should" be), and why 3.45 times-per-year is a good answer for maximum growth (and, again, why we need a centralized decision on that).

--
Gavin Andresen