The main concern is how RBF affects fee rate calculations and the prioritization of transactions within the mempool, considering the introduction of cross-sponsorship where a transaction can change its sponsorship from one package to another based on priority. This raises questions about the effectiveness of the current feerate diagrams.

A significant challenge identified is that the existing heuristic for evaluating transaction packages may not always lead to an improved feerate diagram. The inconsistency could impact miner incentives and ultimately affect which transactions get prioritized. An example demonstrates that a new transaction package might not result in a higher feerate than the existing one. Additionally, the propagation of transactions through the network introduces further complications; locally validated packages may fail to relay under legacy RBF rules due to conflicts with unconfirmed transactions. Wallet authors might avoid these issues by not cross-sponsoring or creating 0-fee parent packages.

The implementation of a cluster mempool architecture adds complexity to the system. If a transaction is divided into parts, there's a risk that while satisfying local conditions, it may not relay successfully in another peer's mempool, leading to incomplete package relay. To address path dependence, programmers suggest limiting the number of RBFs and considering re-linearizing old clusters post-RBF to prevent transactions from getting stuck and to ensure fair evaluation of the required fee bump.

Proposed handling methods for RBF within a cluster mempool include removing conflicts and related transactions, then assessing if the remaining new package improves the mempool before potentially re-linearizing affected clusters and updating the mempool. This approach aims to optimize resource use, only performing computations when they contribute to an improved mempool state.

Additionally, the discourse touches upon the computational complexity involved in replacing transactions within clusters, denoting O(n·log(c)) complexity for creating diagrams, and discusses potential limits to manage this complexity and prevent abuse through excessive RBF operations. They explore managing clusters by capping the number of affected clusters rather than individual transactions to control optimization work after an RBF. This approach's implications on Child-Pays-For-Parent (CPFP) arrangements are also considered.

Finally, practical aspects of implementing feerate diagram comparisons for RBF validation are discussed, focusing on maintaining reasonable computational complexity and avoiding overly large comparison elements. The topic remains an active research area with community involvement on platforms like DelvingBitcoin.org for refining these mechanisms.