When a block reward is spent together with other outputs in the wallet and that block reward is later orphaned, the wallet does not show the other funds as available anymore.  Even a `-rescan` is not enough - only `-zapwallettxes` or an explicit `abandontransaction` "recovers" the funds.  I prepared a [test case](https://github.com/domob1812/bitcoin/blob/wallet-bug-invalidated-block-rewards/test/functional/wallet_bug.py) that shows this behaviour.

Is this a known issue or the expected behaviour?  While this situation is something that will presumably not occur in practice (as it requires a long reorg), I wonder if that transaction should be automatically abandoned as it seems clear it won't be able to be confirmed anymore.
// unavailable as we're not yet aware that it is in the mempool.
    //
    //  broadcast fails for any reason, trying to set wtx.m_state here would be incorrect.
    //  transaction was previously in the mempool, it should be updated when
    // TransactionRemovedFromMempool fires.
    bool ret = chain().broadcastTransaction(wtx.tx, m_default_max_tx_fee, relay, err_string);
    if (ret) wtx.m_state = TxStateInMempool{};
    return ret;
}
stdset<uint256> CWalletGetTxConflicts(const CWalletTx& wtx) const
{
    AssertLockHeld(cs_);
    const uint256 myHash{wtx.GetHash()};
    stdset<uint256> result{GetConflicts(myHash)};
    result.erase(myHash);
    return result;
}
bool CWalletShouldResend() const
{
    // Don't attempt to resubmit if th is configured to not broadcast
    if (!fBroadcastTransactions) return false;
    // During reindex, importing and IBD, old  transactions become
    // unconfirmed. Don't resend them as that would spam other nodes.
    // We only allow forcing mempool submission when not relaying to avoid this spam.
    if (!chain().isReadyToBroadcast()) return false;
    // Do this infrequently and randomly to avoid giving away
    // that these are our transactions.
    if (NodeClocknow() < m_next_resend) return false;
    return true;
}