We were saying basically the same thing here, but I worded it rather poorly.  My thought process was "it's not confirmed until 120 blocks when it's mined, so it's less likely to incur a fee, and the client should send out older transactions (and even newer, bigger transactions when appropriate) first."  Realistically, based on the formula for whether or not to require a fee, when it comes to micro-payments, there is no point in even thinking about it this way.  The send transaction fees are what I was concerned about, though, and I'm glad to see wizkid reconsidering this method.  Realistically, an extreme stroke of luck could cause old EC to turn into unpaid balance, but sending it out as a micropayment when it could happen again just after that payment seems awfully silly.  Considering that it wouldn't be the norm, though, and it wouldn't be a significant amount of BTC.  If we did switch to a "no longer mining" timeout, perhaps the best way to deal with it would be to not reset it, so that if additional backpay was earned after a payout, a miner could get it by mining one share to reset that timer themselves.  Unless active miners want to be able to request a less than .67..., I don't see any reason to add a payout trigger, as not submitting any more shares would be a legitimate request method.  I mean, unless it's unacceptable for the payout to be delayed 7 days after the request.