The suggestion to allow a new lease to override an existing one comes with its own set of challenges, particularly regarding the management of transactions while awaiting confirmation and considering how commitment transactions are affected by previous funding output. There's also the matter of addressing the protocol when a lease concludes. The discussion points towards the necessity for a new communication mechanism to synchronize updates to the commitment transaction, as nodes may not align perfectly in terms of block height. This would inevitably lead to the introduction of a negotiation process for a quiescence session.

Further exploration is given to the scenario where a seller decides to splice into the transaction, with the consensus leaning towards the additional amount being allocated to their unencumbered output. However, concerns are raised about the overall benefits of this approach due to the inherent complexity it introduces to the codebase, impacting various aspects such as splicing, force-close management, and channel reserve. The possibility that sellers might still engage in dishonest practices complicates the situation further, casting doubt on whether the added protocol intricacies truly outweigh the risks and potential issues like compatibility bugs and forced closures.

An alternative perspective suggests simplifying the process by eliminating any CLTV on the seller's side. While this allows sellers more freedom to withdraw their funds at will, it also influences pricing and could lead to a more natural allocation of liquidity based on actual routing activities and user behaviors. If a buyer doesn't receive the expected duration of liquidity, the loss incurred would be minimal, providing a simple resolution by opting not to engage with that node again. This approach seems to better align with the real-world dynamics of liquidity allocation.

To fully assess the implications of these additional complexities, there's a call for more comprehensive coding implementations that support splicing. Only through extensive testing and practical application can an informed decision be made regarding the true value of integrating CLTV-based outputs into the system.