What about trying the dynamic scaling method within the 20MB range + 1 year with a 40% increase of that cap? Until a way to dynamically scale is found, the cap will only continue to be an issue. With 20 MB + 40% yoy, we're either imposing an arbitrary cap later, or achieving less than great DOS protection always. Why not set that policy as a maximum for 2 years as a protection against the possibility of dynamic scaling abuse, and see what happens with a dynamic method in the mean time. The policy of Max(1MB, (average size over previous 144 blocks) * 2) calculated at each block seems pretty reasonable.
As an outsider, the real 'median' here seems to be 'keeping the cap as small as possible while allowing for larger blocks still'. We know miners will want to keep space in their blocks relatively scarce, but we also know that doesn't exclude the more powerful miners from including superfluous transactions to increase their effective share of the network. I have the luck of not being drained by this topic over the past three years, so it looks to me as if its two poles of 'block size must increase' and 'block size must not increase' are forcing what is the clear route to establishing the 'right' block size off the table.
--Andrew Len
(sorry if anybody received this twice, sent as the wrong email the first time around).