A generalized softfork has the same minimum requirements of a standard softfork, i.e. >50% of mining hashpower. In practice it would wiser to shoot for something beyond the bare minimum, such as the standard 75% or 95% of hash power as with other forks. The point is that this proposal is no different than other softforks in terms of requirements.
Hard forks don't need consensus, we just want consensus to actually do one. It only requires the same amount of hashpower to execute. The difference between soft forks and hard forks is not the hashpower required, it is whether the new rules are backwards compatible (soft fork) or not (hard fork)
Besides, this proposal is an alternative to hardforks which completely replace the blockchain with a new version under different rules. My proposal does exactly the same thing, but does so essentially as a softfork. The new chain keeps all the the transaction history on the chain under the new rules.
Nothing about your proposal makes it backwards compatible (a soft fork). It is not possible to still use Bitcoin if you are running an old version of software, as is the case with hard forks. The point of a soft fork is that I don't need to upgrade but I can still send transactions, see confirmations, see other transactions, and consider other transactions and blocks as still valid even if they run under the new rules. Your proposal makes it so that I can't see confirmations (so I can't spend the Bitcoin because the transaction will remain in the mempool and then disappear when no one continues to relay it after it has been confirmed), and it won't consider new blocks containing actual block data as valid since they are too big. It is still a hard fork.