As I've told franky, pools can and will prioritize native-to-segwit and segwit-to-segwit transactions in the case of native-to-native spam attacks.
I've not understood it in its entirety. Is the following mechanism correct: Legacy spam transactions would been recognized and avoided because they would "steal" them computing power for no benefit?
2 MB + SW in my idea would occur in >2019. If Bitcoin's growth continues at the same speed than until now (30-50% transaction volume growth per year) then we could see pretty full mempools then. OK, maybe not if sidechains or extension blocks are functioning.
I don't agree with the instant jumping visions anyways. Why not 1.2 MB now, 1.4 MB next year and so on, until we hit 2 MB? These kind of approaches make more sense to me.
I have no problem with that concept - only that in this case we should do that with a single hard fork (like in BIP 103) to avoid having to fork every year. Still, my favourite are BIP-100-based ideas where the maximum block size has to be "voted up" in small steps, as we've already discussed somewhere.
I was concern about those who hold bitcoin but do not follow the news daily. Maybe those will ignore bitcoin and wait 10 years. What happens then when they find their bitcoin is "prohibited"?
Obviously the whole concept should be made in such a way that if you hold Bitcoin on a legacy key, you could transfer them to Segwit addresses. Only legacy-to-legacy would have to be prohibited.