That’s inaccurate with batching because people can pay out to contracts that contain HTLCs (not that they should, but the payments are still timing sensitive potentially).
One space of a solution would be to have a defined eviction order in the transaction; e.g., spends from output S n+1 > output n or outputs are ordered by value spent with order tiebreaker. I think the decision rule should not look at the spending transaction itself (e.g. for feerate) because it introduces a bunch of problems. The issue with a solution like this is it’s economically irrational, a miner should take the highest fee paying transaction. So these policies can be a stopgap convenience so that people have a better UX with behaving nodes, but it can’t be expected to be followed longer term.
IMO the only real solution is a larger mempool reworking, which decouples accepting and storing a transaction from eviction and from mining more aggressively. That way we can dumbly accept transactions if they connect with no computational risk, evict whenever required, and mine on a best effort understanding of fee rates. The first step in accomplishing this is finishing the MemPool Project first batch of refactors which improve all of our traversal algorithms. Once that is done, we’ll have a better understanding of what we can tolerably raise the limits to with the current architecture (including better carve out limits). Following that, some of these bigger picture modularization refactors can be done as needed. There’s not a strict ordering between these, but it’s easy to change a “pure function” to another equivalent “pure function”, and harder to re architect an entire data structure that will have new behaviors.
