I think that are specifically wrong in saying that you are anti controversial hard forks, I think that increasing the blocksize will always be controversial because of the culture of believe that has now been build up in the Bitcoin community, according to that reasoning we should therefore never increase the blocksize limit? I think this is fundamentally flawed, especially considering how important a parameter this blocksize limit actually is. I think part of the difference in our opinion is that you are also not taking the competition into account.
No, that's not what a controversial hard fork is. A consensus based upgrade (via a HF) of the block size limit is very possible. A controversial fork would be one trying to push only up to a certain percent of miners, which make up a 'majority' or even a minority, which is far different from upgrades based on consensus.
My argument stands on its own, if Core simply increased the blocksize limit to two megabytes it would reunite much of the community and Bitcoin would not be currently suffering from a congested network, which is currently causing transaction delays, increased fees and unreliability.
We have been down this path before,
it is unsafe to do so. Just because you may not know or understand why that is, that doesn't make it any less true. There may even be security issues at 1 MB that are not publicly disclosed for the obvious purposes. Whoever you ask about such, I doubt that they would disclose them outside of their 'inner' circles due to safety reasons.
I know you like to paint me as being an extremely unreasonable person, however what I am proposing here is very reasonable, most people outside of this field would recognize that the small blockist are taking an extreme and fundamentalist position. Most big blockist are applying pragmatic rationalism. Ideally I would just remove the blocksize limit completely or use an adaptive blocksize, as a compromise we proposed the mechanism within Classic, for an increase to two megabytes, we went from 20MB to 8MB and finally to 2MB, and I could argue using Bitcoin Unlimited we could even agree to a 1.1MB blocksize limit. There has been zero compromise from the small block camp, after 18 months. There is not even a blocksize limit increase on the Core road map.
As soon as the quadratic validation time problem has been solved, I see a semi-near future in which it is possible to increase the block size to a total of ~3-4 MB (includes the base expected amount that Segwit should provide, which is around 180%, i.e. 1.8 MB). However, the parameters are certainly going to be much different that you guys are expecting them to be. Doing a HF, which requires ALL custom implementations to be upgraded (this takes time for big businesses) just for a block size limit upgrade is also inefficient. The next HF should be optimally carry desired changes that require a HF in addition to a capacity increase with a grace period of 6-12 months.