Not too sure but I think the reason we can't just do 2mb instead of 1 is because we would need to fork again
Throwing it at 20mb should resolve the issue for quite some time.
What I support most strongly is that we do substantially-delayed hard forks with conservative values. Then doing hard forks regularly isn't such a big issue.
For example, Bitcoin Core can be immediately modified to increase the max block size to 2 MB
on a specific date 2 years from now. I think that pretty much everyone would be basically OK with this max block size (and even higher values might be widely acceptable). By the time the change actually takes effect in 2 years, everyone will already have upgraded because very few people use 2-year-old software. Businesses and users won't have to go out of their way to choose one fork over another, and so there will be less room for messiness.
Then if a really nice academic study convincingly arguing that 5 MB blocks are safe is published 1 week after the 2-year-delayed change is added, another 2-year-delayed change can be added right away with very little extra cost. After ~2 years, the max block size will increase to 2 MB, and then a week later change to 5 MB.
Yes, 2 years is a long time. But I'm confident that Bitcoin will survive that long with 1 MB blocks.
I think this is a good idea but slightly too conservative. Have all the changes implemented in Bitcoin core but have them set to initiate at some future block to scale up more naturally.
I think this would be very conservative-
In ~6 months = Increase to 2MB limit
In ~12 months = Increase to 4MB limit
In ~2 years = Increase to 8MB limit
In ~4 years = Increase to 16MB limit
Than we can re-evaluate the needs further at that time. It should also be a good idea to do more testing with 20MB and larger blocks as Gavin has been doing so if we need to do a sudden hardfork to keep up with transaction demands we always have a well tested option we can use.