The underlying problem is that commitment transactions need to surpass the dynamic minimum mempool feerates of nodes in order to be admissible to mempools. When there is a huge spike in blockspace demand, mempools may overflow and begin evicting transactions. This may raise the bottom feerate of nodes’ mempools beyond prenegotiated feerates of commitment transactions. Those commitment transactions would then no longer be able to reliably close channels unilaterally. Some node implementations therefore preemptively close channels on feerate spikes.

With the release of Bitcoin Core 28.0 we will get opportunistic package relay for child-pays-for-parent transaction pairs. This will allow Lightning Commitment transactions to be submitted into mempools even if their individual feerate is lower than nodes’ dynamic mempool minimum feerates by sending them alongside a child transaction that raises the package’s feerate above the mempool minimum. Hopefully this work in Lightning implementations will progress quickly after the Bitcoin Core v28 release.