It is emphasized that batching splices with JIT channel openings is not feasible due to the nature of JIT operations, which open channels in response to forwarding Hash Time-Locked Contracts (HTLCs). This necessitates a nuanced approach to coordination between peers, akin to the channel_ready signaling but tailored for splice operations, introducing concepts like splice_cancelled or splice_ready. Such coordination is crucial as it requires implementations to actively monitor blockchain transactions rather than relying on timeouts. This is because splice transactions, while remaining valid, can be unconfirmed for an extended period due to mempool congestion, during which there's a risk of double-spending by the peer.

Furthermore, the discourse suggests the need for protocol-level messaging, such as a splice_cancelled message, to facilitate better communication and management of splice operations. This aspect underlines the potential incentives for participants to disrupt splice agreements, particularly to penalize others for moving funds without incurring routing fees that would otherwise benefit them in a traditional LN setup without splicing. The traditional model incentivizes routing through fees, whereas splicing allows for fund movement without direct compensation to those facilitating the network's liquidity.

To address these challenges and potential disputes over splice operations, it's proposed that there should be mechanisms to reject incoming splice-out requests. Additionally, the conversation points towards the introduction of negotiation facilities within the LN for determining in-network fees for splicing out. These measures aim to ensure fair compensation for participants affected by splice-outs and maintain the integrity and incentive structure of the LN ecosystem. This dialogue underscores the intricate balance between innovation in payment channel technologies and the necessity of maintaining a cooperative and mutually beneficial network environment.