The mempool is not one pool

A mempool is ordered by fee rate, not by arrival time. The relevant figure is the fee a transaction pays divided by the weight it consumes, because a block has a fixed weight budget and a miner filling it wants the most fee per unit of that budget. A transaction that pays a large absolute fee but consumes a great deal of weight may rank below a smaller transaction paying less. This is why fee estimation is expressed per unit of weight, and why the block weight rule is the right frame for thinking about fees.

When a mempool reaches its configured size limit, the node evicts entries from the bottom of the fee-rate ordering until it is back under the limit. Eviction is not a rejection of the transaction's validity; the transaction remains valid and may still be confirmed if another node kept it and a miner includes it. But the node that evicted it will no longer relay it, and if enough nodes evict it the transaction may effectively disappear from the network's view until it is rebroadcast.

Replacement works in the opposite direction. A node that receives a transaction spending outputs already spent by an unconfirmed transaction in its mempool must decide which to keep. The rule the reference implementation applies is that the replacement must pay a fee that exceeds the original by a margin, and must compensate for any descendants of the original that are displaced. The effect is that a sender who underpriced a transaction can raise the fee by replacing it, provided the increase is large enough to be worth the node's attention. This is the mechanism behind fee bumping, and it is a policy rule rather than a consensus one.

There is no global mempool, and this is the fact most often lost in discussion of fee rates. Each node holds the transactions it has happened to receive, subject to its own policy, and the sets differ between nodes for entirely ordinary reasons. A node that was offline for an hour missed whatever arrived during that hour. A node with a higher minimum fee rate never accepted the cheap transactions in the first place. A node that evicted entries under pressure holds fewer than one with more memory. Two honest nodes can therefore disagree about what is pending without either being wrong.

This is why a fee estimate is a prediction rather than a reading. When a wallet asks a node what fee rate is likely to confirm a transaction soon, the node is answering from its own view of its own store, and that view is a sample rather than the whole. The estimate is useful because most nodes see most transactions most of the time, so the samples agree broadly. It is not exact, and it cannot be, because the thing being estimated does not exist as a single object.

The same reasoning explains why a transaction can appear stuck on one explorer and pending on another, and why a transaction that seems to have vanished may simply have been evicted from the nodes an observer happened to query. The node verification page sets out the checks a transaction passes before it is held at all, and the UTXO model page explains what a transaction spends when it is finally confirmed.