Transactions – Understanding Reasons for Stuck and Cancelling Transactions

I still don't know why eth.resend was failing (and continues to fail as of geth 1.6.5), but this compatible patch works for me:

eth.resend = function (tx, gasPrice, gas) {
  if (gasPrice) {
    tx.gasPrice = gasPrice;
  }
  if (gas) {
    tx.gas = gas;
  }
  tx.data = tx.input;
  return eth.sendTransaction(tx);
};

I prefer to also add this convenience version:

eth.resendgwei = function (tx, gasPriceInGwei, gas) {
  if (gasPriceInGwei) {
    return eth.resend(tx, web3.toWei(gasPriceInGwei, 'gwei'), gas);
  }
  else {
    return eth.resend(tx, null, gas);
  }
};

Now, if your pending transaction is stuck because the gas price is too low, you can speed it up with:

eth.resendgwei(eth.pendingTransactions[0], 27);

My understanding is that your understanding is correct, except you're missing one particular property of the Ethereum node software. Namely, as part of #3, the transaction is stored in the node's transaction pool (cf. Bitcoin's mempool). Normally, the transactions live there until mined, but because computers have finite memory and processing power, the transaction pool is, by necessity, also of a finite size. Transactions that have not been mined may be evicted from memory if the transaction pool is full (I assume the ordering is implementation dependent -- presumably, higher value transactions are kept). So your transaction probably got evicted from Etherscan's transaction pool, but was "recirculated" by another node after Etherscan's transaction pool freed up some memory.