That's not a very good description of what Luke's (latest) Hard Fork plan actually is; the blocksize limit depends on absolute blockheights in his proposal, and so whether or not the blocks are bigger than 1MB or smaller depends on when the fork is activated.
If that hard fork activated tomorrow, we'd have 300 KB blocks. But that's very unlikely to actually happen. By the time a fork proposal like that activated, it could easily have reached the stage of progress where the blocksize is bigger than 1MB (I think Luke is using the 17% per year "technological growth" factor that Pieter Wuille did in BIP103)
I think it's a fair description of what it is. It initially lowers the block size, which is exactly what I wrote. Take a look here:
if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.
Block size is only going above 1 MB in 2024 with his proposal.[1]
If you want a block size increase for all ( I suppose ) , you do not need compli seg wit (might work for a few).
Segwit is required to fixing the quadratic hashing problem in this aspect. It comes with plenty of other benefits as well.
Im pretty sure the rest of the Core team is okay with raising to 2MB after segwit is implemented, so we must get segwit going. It's funny that the same idiots that are complaining about lack of blocksize increase are blocking segwit and by doing so blocking any real chances of a blocksize increase.
The problem is that there is no hard fork proposal that does this. Someone should create one that builds on Segwit and raises the block size by a certain amount.
[1] -
https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki