Following this process, starting with original = 1 and current = 1:

1. new = 0; deducts 5k gas and adds 15k gas to the refund counter; current = 0.
2. new = 1; adds 4800 gas to the refund counter
3. Goto 1.

Thus for every 5k gas deducted from the gas meter, we can add 19800 gas to the refund counter.

Fixed! Added an additional clause when storage slot is dirty. If original value is not 0, if current value is 0 (also means that new value is not 0, because of the parent clause "If current value does not equal new value"), deduct 15000 gas.

1. new = 0, original = 1, current = 1; deducts 5k gas and adds 15k gas to refund counter.
2. new = 1, original = 1, current = 0; deducts 200 + 15k gas, adds 4800 gas to the refund counter.
3. original = 1, current = 1; goto 1; for every round 200 + 20k gas is deducted, and 19800 gas in the refund counter.

This seems reasonable. A couple of critiques:

• Unlike the existing proposal, this can result in consuming a lot of gas and adding it to the refund counter. Since refunds are limited to 1/2 the total gas used, you could easily end up paying more than expected if you set a value to and from its original value a number of times.
• It's hard to follow the logic here. Some diagramming, or breaking down the cases more would help.

Thanks! I think (1) is a really good point. If there're cases where it can cost a lot most gases compared with the current scheme, then we may break backward compatibility for existing contracts. So in 23ebc94 I changed the clause from deducting 15k gas to removing 15k gas from refund counter. In this way, we will never consume more gases compared with current scheme. Indeed, this adds a new semantics for gas refunds (we never removed gas from refund counter before), so I'm definitely open to better ideas on this. The current rationale/assumption for this is:

• Backward compatibility is important.
• We can prove that refund counter will never go below 0.
• This new semantic of removing gas from refund counter is trivial to implement in most clients.

Talking about other cases where it may cost more gases compared with EIP-1087 -- it happens with sub-call frames to the same contract where we cannot track the dirtiness. But I still think it may be worth the trade off because:

• We don't suffer from the optimization limitation of EIP-1087. After EIP-658, an efficient storage cache implementation would probably use an in-memory trie (without RLP encoding/decoding) or other immutable data structures to keep track of storage changes, and only commit changes at the end of a block. For those implementations, we cannot efficiently iterate over a transaction's storage change slots without doing a full diff of the trie.
• It never costs more gases compared with current scheme.
• It covers commons usages like reentry locks, same-contract multi-send, etc.

Still working on (2). Let me try to see whether there are clearer ways to describe the spec.

Added an explanation section to make the logic more clearer!

Wouldn't this be clearer if one axis had (current, original) and the other axis had new?

I think you have 'horizontal' and 'vertical' reversed here.

Oops! Fixed!