> I think this avoidance of a circular reference is also why LN-Symmetry uses the annex?
The annex trick specifically is used to force the publication of the missing piece of the control block corresponding to the new taproot output. This is to maintain the node's O(1) state while also keeping 0.5RTT channel updates. Could have also been done with a dangling OP_RETURN, with the associated restrictions on which sighashes you can use since you now have to commit to multiple outputs(disallows SIGHASH_SINGLE).
There's also a fair exchange protocol that obviates the need for it using signature adapters, but the requisite APIs don't exist yet, and doesn't lend itself naturally to 3+ party scenarios.
> Depending on policy to mitigate this annex malleability vector could mislead developers into believing their transactions are immune to replacement, when in fact they might not be.
The issue I'm talking about is where someone's transaction is denied entry into the mempool entirely because a counter-party decided to put in a strictly worse transaction for miners by bloating the weight of it, not adding fees. A strictly worse "API" for paying miners for no gain seems like a bad trade to me, especially when there are reasonable methods for mitigating this.
> It may thus be more prudent to permit the utilization of the annex without restrictions, inform developers of its inherent risks, and acknowledge that Bitcoin, in its present state, might not be ideally suited for certain types of applications?
Mempool policy should be an attempt to bridge the gap between node anti-DoS and an entity's ability to pay miners more via feerate-ordered queue. I don't think the answer to this problem is to zero out all ability to limit the sizes of multi-party, multi-input transactions for speculative use cases.