The discussion around whether to include a to_remote_anchor output only when a to_remote output does not exist reveals contrasting opinions on efficiency and necessity within transaction construction.

On one hand, it is suggested that when a to_remote output disappears in channel transactions, an anchor output should be introduced as a replacement, paid by the channel initiator. This approach supports mobile wallets through 0-reserve channels but raises concerns about small dust outputs that could permanently bloat the UTXO set if unclaimed. In contrast, anchor outputs can be claimed after a certain number of blocks, providing a cleanup mechanism. However, the relative merits of this proposal versus alternative strategies are still under debate.

The counterargument posits that creating a to_remote_anchor output may not be necessary, suggesting instead that opening a channel with a minimal balance on the to_remote output might be more efficient. The analysis touches upon the upcoming version 3 (v3) transactions, hinting at a cleaner approach to these issues.

A specific vulnerability is identified concerning the use of remote anchors. A scenario is outlined where Alice opens a channel with Bob, who initially lacks a main output in the commitment transaction. If Alice does not reciprocate Bob's commitment signature, she could broadcast her own transaction, requiring a remote anchor to ensure Bob can claim HTLCs before they time out. This situation underscores the need for such an anchor due to the lack of package relay and the potential for Alice's transaction to win mempool precedence, impeding Bob's ability to use Child Pays for Parent (CPFP) techniques effectively.

Technical references to BOLT 3 clarify the conditions under which anchor outputs are added to commitment transactions. It is further explained that current transaction structures employing CSV delays prevent the immediate use of the to_local output for CPFP, while to_remote outputs could theoretically allow it. Nonetheless, the implementation of both local and remote anchor outputs is criticized as a flawed design, leading to unnecessary chain space consumption.

The conclusion drawn from these discussions indicates a possible overcomplication in the handling of to_remote outputs, as their immediate spending behavior contrasts with treating them as normal wallet outputs. Future considerations involve the feasibility of omitting the to_local anchor when HTLCs are active, albeit with increased implementation complexity and careful analysis of the permissions related to HTLC spending.

This summary has retained pertinent information and links regarding the debate on Lightning Network's transaction designs and optimizations, avoiding any salutation elements as per the stipulated rules.