Thanks for laying out a road-map, Greg.
I'll need to think about it some more, but just a couple of initial reactions:
Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the coinbase is messy and will just complicate consensus-critical code (as opposed to making the right side of the merkle tree in block.version=5 blocks the segwitness data).
It will also make any segwitness fraud proofs significantly larger (merkle path versus merkle path to coinbase transactions, plus ENTIRE coinbase transaction, which might be quite large, plus merkle path up to root).
We also need to fix the O(n^2) sighash problem as an additional BIP for ANY blocksize increase. That also argues for a hard fork-- it is much easier to fix it correctly and simplify the consensus code than to continue to apply band-aid fixes on top of something fundamentally broken.
Segwitness will require a hard or soft-fork rollout, then a significant fraction of the transaction-producing wallets to upgrade and start supporting segwitness-style transactions. I think it will be much quicker than the P2SH rollout, because the biggest transaction producers have a strong motivation to lower their fees, and it won't require a new type of bitcoin address to fund wallets. But it still feels like it'll be six months to a year at the earliest before any relief from the current problems we're seeing from blocks filling up.
Segwitness will make the current bottleneck (block propagation) a little worse in the short term, because of the extra fraud-proof data. Benefits well worth the costs.
------------------
I think a barrier to quickly getting consensus might be a fundamental difference of opinion on this:
"Even without them I believe we’ll be in an acceptable position with respect to capacity in the near term"