tl;dr Non-mining nodes can in principle receive compensation for transaction handling without radical changes to Bitcoin.
I don't see why you think this is relevant. Other nodes relaying plays no role in the economics of mining: miners can (and already do, and
have in the past since 2011) advertise locations which can receive transactions for them, and can do so trivially and in a jamming proof way by listing them in the blocks they mine. Transactions then go straight from users to miners, which is inherently more efficient since the multi-hop flooding network relay was just pure overhead (a product of trying to achieve decentralization at great bandwidth cost). Anyone can "in principle" pay anyone else, sure. But there is no obvious reason for anyone to do so.
foolish_austrian, I'm very interested in that kind of closed loop control vs difficulty... In the past when I'd worked on it's I'd struggled at producing a difficulty size relation which was well justified, there seem to be an infinite class of functions that works just about as well. "Why this shape and not this other one?". Have you considered an absolute floor (e.g. size limit can't go below 1MB regardless of what the average size is) and if that creates weird incentives?
I tried doing some work where I assumed there was a unimodal optimum quantity and tried to prove (for some function) that the system would always find equilibrium there but I was unable. All these 'quadratic curve' like systems do have a nice property that differences in miner efficiency turn into differences in the block sizes they produce, thus equalizing their participation some-- more efficient miners produce larger blocks than typical rather than just driving people out of the market quite so strongly (though this is less powerful when you assume transaction fees/byte are power-law rather than uniform)... but I was unable to prove that even with homogenous-cost rational miners if there is a single supply level at which miner income is maximized that the system has an equilibrium there. I think it would be really good to be able to show that.
Back to your writeup; can you check your figures? because the function you've shown there doesn't obey the invariant that the result should be 1 if s,d = 1. Using 1/2 as both your coefficients does, but disagrees with your illustrations; did you have some scale and offset you're not listing here?
Subsidy can be addressed by scaling it with the function (e.g. 2x difficulty, you get 2x the subsidy) and just letting it modulate the move the inflation schedule in or out somewhat, so the subsidy is neutral to the process... though it's annoying because it makes it more complex and harder to reason about. Your notion of having coin-holders influence the target hashrate growth target is interesting; though if you do so internally to the network with transactions miners can censor them to change the result so some care and thought must be taken there. It sort of combines a proposal I liked before (basically only increasing the block size if there is enough coins days destroyed voting for it) but thought perhaps was too costly to use directly.
As far as implementation goes, ... using floating point in consensus would be an unmitigated disaster. But thats no problem, a reasonable, cheap, fixed point approximation is no problem-- esp. for the limited range this function needs to operate over, a rational polynomal fit will work fine.