I do have to add that, while I think that it would be still extremely hard to gather 90-95% consensus on
both ideas, I think both would reach far higher and easier support than either Segwit or BU.
I don't understand that statement. Are you talking about DooMAD's idea (modified BIP100+BIP106) or the compromise proposed by "ecafyelims", or both?
I ask because I think DooMAD's "10%-blocksize-change-voting proposal" sounds interesting and if there is support by staff/respected community members/devs then it would be worth discussing it in a separate thread to elaborate a "final BIP".
Core would not because they're all convinced we must have segwit before increasing the block size to prevent a quadratic scaling sigop DDoS happening... though segwit doesn't change the sigops included in regular transactions, it only makes segwit transactions scale linearly which is why the blocksize increase proposal is still not on the hard roadmap for core as is.
Well, if I understand right (as a [almost] non-programmer) then that problem could be solved by coding the change proposal in a way that explicitly delays the hardfork until
a lot of time (several months) has passed after the Segwit activation. That should be possible - it would then signal the "big blockers" that their desired blocksize change will come, but would give the system time to adopt Segwit transactions.