Which is why this is a hard fork. Old clients will outright reject the new chain with the larger blocks.
This is why I called it a "generalized" softfork, since it has properties of softforks but has the power of a hardfork (in this case). It is sort of an "in-between" kind of fork.
If a "significant portion of the hashpower refuses to upgrade" to your proposal, then all they have to do is had code in a rejection of one of your blocks and "Bitcoin will split into two completing cryptocurrenies that can co-exist forever".
I do not disagree but the same it true for all softforks (e.g. OP_CLOCKTIMEVERIFY).
I'm curious, how does your intended solution expect to deal with the situation where the old format has a longer chain? This would mean that the old network would reject the transformed chain, but how would your system be aware that the transformed chain was rejected and what would it do with all those transactions that had been confirmed in it's big block chain?
Since this is a (generalized) softfork, there is a very strong incentive for miners to upgrade to the new rules (orphaned blocks). So this should not happen provided the majority hash power are on board when the fork occurs.
However, if it *did* happen, then this is a disaster no matter how the fork is designed. Either the old (longer) chain is rejected as invalid, or there is a very large reorg undoing many multi-confirmation transactions.