So currently, if I’m reading correctly this is a MAY and not a SHOULD NOT:
- MAY fail the corresponding incoming HTLC sooner.
This could be more precise, as the incoming HTLC might not be included in the commitment transaction. If it’s not included, failing it backward is not a problem. If it is included, this is a different problem as a routing LN node as it’s all depends the mempool feerates at the time of failing backward. With anchor output, the feerate cost to confirm the commitment_tx on the incoming channel could be higher than the received HTLC’s amount_msat.
That is an orthogonal problem. The decision of whether to claim an HTLC on chain or not (because it would be uneconomical) is independent of the decision to fail back off-chain .
Sure, however if the decision to fail back is not materialized on-chain (see comments above), this only works if the LN channel counterparty is cooperative, and I think the implicit assumption with BOLT5 (“Recommendations for On-chain Transaction Handling”) as a LN node cannot rely on interactivity with the counterparty to decide to go on-chain or not.