Here is a reading of the 90th percentile (ie. 10th from the bottom) of gasprice in gwei in a span of 100 blocks (5500000…5500099):
[1, 1, 2, 1, 1, 1, 1, 1, 20, 1, 1, 4, 1, 1, 1, 50, 1, 4, 1, 5,
0, 1, 1, 1, 1, 1, 1, 1, 0, 2.2, 1, 1, 1, 0.646, 1, 1, 1, 5, 2.2, 1,
1, 1, 1, 1, 22, 1, 0, 4, 1, 1, 1, 1, 22, 1, 1, 1, 1, 1, 0.646, 0.646,
1.01, 1, 4, 1, 1, 1, 0.5, 1, 1.01, 4, 1, 5, 2, 1, 1, 1, 1, 6.71, 2, 1,
1, 5, 1, 1, 1, 1, 1, 1, 5, 20, 1, 5, 1, 1, 5.6, 1, 5, 1, 2, 1]
So it definitely is volatile. And it’s volatile because block-by-block gas usage really is volatile. What I’m suggesting would turn that block-by-block price volatility into block-by-block usage volatility, reducing costs and delays for participants at fairly little cost. Also, the median gasprice paid is ~2.8x higher over that timespan, and the average is ~4.9 times higher. So plenty of people are overpaying quite significantly.
With the min gas price strategy, if the next block isn’t full (or rather, isn’t 50% full) then the min price decreases slightly but the user with the lowball gas price will not get included. They will have to wait until the min-gas-price decreases all the way to their target, which could take a long time depending on how much they lowballed.
Not if you use the version where the user can specify “I’m ok with paying whatever the mingasprice is, up to a maximum of X, plus k%”. Then users really would be able to just fire and forget, and get a guarantee that their tx gets included as cheaply as it can be, unless the price goes above what they are willing to pay.