I am curious if we considered not deleting transactions from the pool of received transactions? In other words, back the mempool with a db store.
As transactions get pushed out from the mempool by better fees transactions, we eject them from the mempool and store them to disk/db instead. Later we can fetch them from the db when required instead of reaching out to a peer.
This might also help with the problems that we are trying to solve using package relay of transactions. Not sure about this, but it could have an impact.
I think libbitcoin does not delete any received transactions, ever. Which avoids problems like trying to fetch them over the network if they are later required. There is no mempool there and instead the same transactions table holds all received transactions, spent or unspent. As long as they are unspent they can be used to construct next block.
In Core, the problem will be to delete txs from the mempool backup store when txs are spent. This will have a performance penalty. Maybe the libbitcoin solution of a single txs table is worth looking into again? One store, for all rcvd txs, spent or unspent and never delete them.
Regarding spam txs, we need the same defences we use against spam when protecting mempool.