It's a problem today in contexts such as sidechains where there is no block subsidy. That's why we were looking at this exact proposal internally at Blockstream (alas, I can find no public descriptions of the idea, so we've been scooped!). I share gmaxwell's concern that there seem to be an infinite number of possible curves to use, and it is not even obvious what metric should be used to rate them. It would be ideal to show that for various distributions of priority/fee-per-kb in the mempool that there exist Nash equilibrium mining strategies which result in a stable block size. The block size adjustment algorithm must also do something to mitigate centralization pressures of larger block sizes -- larger blocks make better connected miners have larger apparent hash rates than they actually do, due to differences in propagation time. Neither of these are well formalized yet, and there may be other requirements remaining to be discovered.

A few minor notes: since the difficulty is specified in the block header, it is possible for the miner to choose a block size which is possibly greater than the actual block size by adjusting their reported difficulty (the bits field of the PoW). Additionally, for bitcoin you have the question of whether or not to adjust the subsidy by the same factor. Arguments for and against adjusting the subsidy have to do with whether you want there to be a near-term cost to adjusting the block height.