Overall this looks like a good approach but if you are doing this level of revamp I would take a closer look at how you handle state bytes. Transactions which reduce net state usage should have zero or negative cost for state (negative cost would mean crediting RCs back to the user), and transactions which use state for a longer period of time should cost more than those which use it for a short period of time. Permanent state should perhaps be a separate resource pool of its own and only grow at a very slow rate (making it relatively expensive to use)

State is not really something which can simply grow at a set-rate per block, unless the rate is extremely low (comparable to the rate of hardware technology improvements). Setting a per block rate this low without some allowance for reduction in state usage will probably constrain blockchain utility greatly, and setting the limit too high will open paths for cheap denial of service attacks.

State limit is more of a static parameter (as a function of hardware realities) should perhaps be set by witness vote or community consensus (hard fork). Approaching the state limit should increase the price of adding any state (not per block) and likewise the benefit of reducing state usage.

In any case, this proposed model is certainly an improvement over the status quo which attempts to price everything (including both temporary and permanent state) into bandwidth.