While the on-chain logic of a LN state machine is notoriously hard to implement correctly and BOLT5 is infamously known to not be exhaustive, there is one remark to be made on the proposed specification patch.
If I’m understanding correctly, the new requirement would apply to the situation where a local node has offered an HTLC output, said output included in a remote commitment transaction. If this offered HTLC is not included in the latest commitment transaction, it is proposed to fail the corresponding received HTLC on the incoming pair of commitment transactions.
If my memory is correct, this new mechanism has been already discussed in the past with few LN maintainers and devs in considering some other class of attacks. However, implementing this mechanism comes with the effect that now a LN node force-closes of the incoming channel, even if there is an economic disproportion between the HTLC at risk and the on-chain fee cost to force-close the channel. There is no guarantee on the interactivity of the backward peer. E.g the HTLC might be worth 1000 sats and the force-close absolute fee cost might be 10_000 sats. As far as I remember, there was no convergence among the LN maintainers of each implementation at the time, what should be the best in this situation and if the fall-back shouldn’t be an implementation policy or a node settings detail.
That it can be still worthy to have a description in BOLT5 of what can be a correct behavior, that I don’t disagree.