do pools prioritise LEAN transactions to allow more transactions in.. nope
Because this is equal to censorship. Additionally, the average TX size is well above the "lean transaction size".
do pools prioritise mature transactions to evade spammers.. nope (spam: those that intentionally respend every block)
Immature transactions does not necessary equal to spam.
do pools prioritise transactions with fee.. nope (empty blocks/btcc zero fee confirm)
Yes they do (not always obviously). You have no argument as usual.
We could spam the testnet for that if nobody does it.
That does not equal to real world testing unless you can mimic the whole network on a smaller scale.
Your point is, I suppose, that someone would hold back spam attacks until the maximal block size becomes big enough (e.g. 8 MB)?
They could hold back or spam right away. Either way, an attack vector must not be left in the air at any cost.
Wouldn't then the quadratic hashing time problem be unsolved forever? Because the problem seems to be the danger of spam attacks based on that problem, and if non-Segwit tx are possible then a spammer obviously will use them. I think as long as it is possible to transfer non-segwit outputs to segwit keys (non-segwit to non-segwit would be the possibility that would have to be prohibited) the precedent is not dangerous.
Yes, the quadratic hashing problem will exist until it gets sorted out via a hard fork (see the Flextrans proposal, which is a HF proposal similar to SW but vastly inferior even though the incompetent devs claim its superiority). 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.
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.