In terms of your frameworks, I don't know what I am describing.

I thought that I was describing part of the dynamic of the historical propositions of XT, Classic and BU, which was that they were wanting to achieve a change in the governance - but they were arguing that there was a technical necessity that was justifying their position.. so each time, there was a threat of a hardfork in the soon future in the event that core did not accommodate in order to make the technical change (which was argued to be an upgrade to 2mb blocksize limits).  Initially, in about late 2015, Segwit was communicated as a compromise change to the code that would partly address scaling issues without a need to hardfork or to immediately implement a 2mb increase or further increases or changes to governance that would allow increases to be easier in the future... or even the automatic increases that were initially part of the XT proposition.

Anyhow, I was just suggesting that the arguments about technical necessity were merely guises to allow for easier future changes by either having the changes automatic or changing the process in order to allow for easier future changes (which are all significant changes to governance - that makes it much more difficult to make changes to bitcoin).

Initially, in late 2015, it seemed that a large number of folks were onboard with segwit; however, with the passage of time, there has been more expressions of disagreement about it - but still seemingly that a lot of the disagreements have been dressed up in terms of concerns about technicalities, when in reality there are underlying motives that are ongoing attempts to change governance and to make it easier to change bitcoin in terms of how BIPs are made, discussed, tested and implemented through procedures followed by core...and seemingly some hate regarding the influence over the procedure of some of the core personalities.