> 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.

Just to expand this, an example would be a transaction with inputs A' and B' signed by two parties A and B. A has a fully signed transaction in hands, but can't publish it because B created and published an alternative version of it with a large annex for input B'. Wouldn't miners just accept A's version because it's fee rate is higher? I am looking at this case assuming the user has a direct connection to a miner, ignoring any potential concerns related to p2p transport.

Joost