Cluster mempool has always been one of those things that I've struggled to wrap my head around. But the time has come that I must at least begin, because how Core mempools behave is getting a pretty good overhaul in Core 31.

Here's how the v31 release notes describe it:

• The mempool no longer enforces ancestor or descendant size/count limits. Instead, two new default policy limits are introduced governing connected components, or clusters, in the mempool, limiting clusters to 64 transactions and up to 101 kB in virtual size. Transactions are considered to be in the same cluster if they are connected to each other via any combination of parent/child relationships in the mempool. These limits can be overridden using command line arguments; see the extended help (-help-debug) for more information.
• Within the mempool, transactions are ordered based on the feerate at which they are expected to be mined, which takes into account the full set, or "chunk", of transactions that would be included together (e.g., a parent and its child, or more complicated subsets of transactions). This ordering is utilized by the algorithms that implement transaction selection for constructing block templates; eviction from the mempool when it is full; and transaction relay announcements to peers.
• The replace-by-fee validation logic has been updated so that transaction replacements are only accepted if the resulting mempool's feerate diagram is strictly better than before the replacement. This eliminates all known cases of replacements occurring that make the mempool worse off, which was possible under previous RBF rules. For singleton transactions (that are in clusters by themselves) it's sufficient for a replacement to have a higher fee and feerate than the original. See https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#rbf-can-now-be-made-incentive-compatible-for-miners-11 for more information.
• Two new RPCs have been added: getmempoolcluster will provide the set of transactions in the same cluster as the given transaction, along with the ordering of those transactions and grouping into chunks; and getmempoolfeeratediagram will return the feerate diagram of the entire mempool.
• Chunk size and chunk fees are now also included in the output of getmempoolentry.
• The "CPFP Carveout" has been removed from the mempool logic. The CPFP carveout allowed one additional child transaction to be added to a package that's already at its descendant limit, but only if that child has exactly one ancestor (the package's root) and is small (no larger than 10kvB). Nothing is allowed to bypass the cluster count limit. It is expected that smart contracting use-cases requiring similar functionality employ TRUC transactions and sibling eviction instead going forward.

Bitcoin Optech has a pretty good page on cluster mempool as well, that gets in to why cluster mempool is useful:

Each cluster contains feerate-sorted chunks consisting of one or more transactions. If we limit a cluster’s size, we also limit how much needs to be recomputed in response to new transactions being added to the mempool, allowing algorithmic decisions affecting the entire mempool to complete fast enough to use them in P2P network code.

The overall goal of cluster mempool is being able to reason about the effect of transactions on the blocks a miner would create if it has an identical mempool to the local node’s mempool.

The most apparent example of why we need that kind of reasoning is the fact that today, the eviction mechanism (when the mempool exceeds the node’s size limit) can choose to evict the very best transaction in the mempool overall (example).

To describe the current limitation in short: miners prefer to select for inclusion the transactions in order of highest ancestor-feerate first (feerate of a set formed by a single transaction and all its unconfirmed ancestors). Eviction removes transactions in order of lowest-descendant feerate first (feerate of a set formed by a single unconfirmed transaction and its descendants). This mechanism is certainly suboptimal (highest ancestor-feerate first is just an approximation for highest-feerate subset overall, and e.g. can’t deal with multiple-children-pay-for-the-same-parent), but more problematic is the fact that eviction isn’t the exact opposite of transaction selection: they’re both approximations, and the ways they are suboptimal don’t cancel out, so they don’t result in the opposite order of each other.

Finally, I saw this post on X today that attempted to describe cluster mempool:

one of the changes expected to be included in Core 31 is Cluster Mempool

transactions in the mempool are nodes with fee, weight, and dependencies. this creates a DAG (directed acyclic graph) structure where transactions are interdependent. any valid block must respect these relationships and include ancestors when selecting a transaction

this leads to the Maximum Ratio Closure problem: selecting a closed subset that maximizes fee relative to weight, and turns block construction into a graph optimization problem

previously, the mempool was treated as a flat set of independent transactions and now the Cluster Mempool groups connected transactions and evaluates them as graphs

this impacts CPFP, fee estimation, and RBF algorithms (become more complex due to graph interactions)

I have to admit that I didn't find this explanation helpful. Curious if anyone has other resources for understanding the implications of cluster mempool changes.