ok imagine this
its a month after the 75%.. and it is block height 400,000
then "one miner with a small modicum of relative hashpower to produce a single block that violates the 1MB limit" decides to make block 400,001 with 1.1mb
guess what
if the minority miners (under1mb) dont stale their attempt as they reject the 1.1mb block and so the minority miner makes its own 400,001 of 0.9mb

next the minority miner makes 400,002 and because it came first and does not hold any blocks over 1mb.. when the miner that makes the bigger block receives it..

it says "oh crap i dont have the same blockheaders, lets ophan off the large block and get the valid blockheight version of the chain.
here is some animation because some people like pretty pictures and dont understand words

A= <1mb miner B=<1mb miner C=<2mb miner


2mb implementations can orphan their large blocks and rejoin the small blocks if small blockers mine a block first(at any time).. which means if small blockers have 20% chance of solving a block first.. then the orphan rate would be 80% because eventually the chain would rejoin to be small blocks and 80% of the large blocks would get thrown out when the chains re-align... in short, some blocks that have upto 4 confirmations could then be thrown out..
yet those on the small block chain dont get orphans.

but the flip side is that if the small blockers never solve a block first, then not only are they wasting hashpower that doesnt result in a block they can spend. but also they wont get to sync and they will be left behind. which means that small blockers would then give in and upgrade or be left wasting their own time.

which is something they should be prepared to do long before miners decide its time to do more than 1mb.

so largeblockers wont push forward until they are absolutely sure their attempts wont get orphaned.. even if the 2mb setting is active it will just sit there until the time is right.. even way after the 28 days have passed.

so although there is a proposal for 70-95% (whatever magic number no one agrees on).. people should start to seriously think about having the buffer of 2mb well before that magic number. even if it takes 2 years for miners to finally add more transactions. having the 2mb setting as a buffer atleast causes less chance of orphans or headaches, when that time finally comes.

nothing forces a miner to push out more than 1mb after consensus magic number has been reached.. its not in the code to generate blocks over 1mb.. and so its miners choice to do so when they think they can handle it and they are sure it wont end up as orphan at sometime..
(i repeated for emphasis)

also where i was saying it is a buffer in other post is because 1mb limit has been a buffer setting while miners were making 0-500k blocks in 2009-2013 and 0.2mb-0.95mb from 2013-2016, yet miners were not forced to only make 0.99mb blocks.. were they?!?

miners can no matter what the blocklimit setting is, .. independently choose how many transactions they want to include. so even if it is a month after 75% or 95% whatever.. miners can still make sub 1mb blocks and just have the 2mb limit sat there, without issue

Group C (2MB miners) finds and publishes Blocks 400,000c, 400,001c and 400,002c (all > 1MB) at 12:05-12:15, making it the longest valid chain by 3 blocks for all nodes enforcing 2MB rules. Groups A or B (1MB miners) finds and publishes Block 400,000a at 12:16.

Now, why would nodes enforcing 2MB rules orphan any of Blocks 400,000c-400,002c? They are valid blocks built on the longest valid chain by timestamp. Block 400,000a was found well after Block 400,000c. There is no reason for 2MB nodes to "re-align" with Groups A or B. To 2MB nodes, Block 400,000a is a stale block and nothing more. 2MB nodes will continue to recognize blocks built on top of 400,002c as valid.

Meanwhile, Blocks 400,000c-400,002c break the consensus rules enforced by 1MB nodes. So for them, the next valid block on the longest valid chain is 400,000a. 1MB nodes will continue to recognize blocks built on top of 400,000a as valid.