It is acknowledged that deploying v3 prior to the cluster mempool would provide a temporary solution to mitigate most pinning vectors, enhancing security against certain attacks where funds might be stolen. Additionally, it's suggested that once the cluster mempool is integrated, the capabilities of v3 could be significantly expanded.

There is a consensus on the preference for Replace-By-Fee (RBF) over Child-Pays-For-Parent (CPFP) for splice bumps; however, due to safety concerns with zero-confirmation transactions, CPFP appears to be the only viable option. The current limitations of RBF in the context of zero-confirmation transactions expose vulnerabilities that could lead to trivial attacks, making its use unsafe.

The conversation further considers the evolution of mempool policy, emphasizing the importance of forward-thinking to avoid subsequent versions beyond v3. To this end, there is a proposition to start with a more restrictive package topology in v3, which can be relaxed progressively, allowing for a smoother transition without needing to introduce a version 4 (v4). The goal is to deploy a simplified initial version of v3 to address immediate issues and then enhance its functionality over time.

A more nuanced approach suggests modifying zero-confirmation funding transactions for compatibility with v3 by adding a shared anchor. This adjustment would enable either party involved in a transaction to use CPFP if necessary. However, it's noted that this method prevents the creation of chains of unconfirmed splices due to the current restriction within v3 that permits only one unconfirmed child, which could be seen as a practical limitation for transaction handling.