Hi John,
I think lightning and other second time-sensitive layers being hit by safety issues whenever the blocks are full is common knowledge as the issue is being described in the paper under the "forced expiration spam" issues arising spontaneously within an environment with high block space demand. I believe you have known variants of those issues with the "flood & loot" style scenarios.
What is coming as a new problem with the novel replacement issues lay in the fact that your counterparty channel might always defer the confirmation of your honest on-chain spend, in a way which is compatible with miners incentives.
While this has been commonized by the wide deployment of bip-125-style RBF over network mempools, this ability has been always available to any party reaching out directly to miners out-of-band with consensus-valid transactions. In a world where miners are pseudonymous (as we're mostly seeing today, not considering pools) miners motivated by maximizing their satoshi-denominated income is a reasonable assumption in my opinion.
As an ecosystem beyond core to fix sustainably pinning and replacement problems, and I agree with you here, we are stuck with a "between Scylla and Charybdis" serious safety issue, I'm seeing the following options. Matching yours, rephrasing in my own words to ensure correct understanding.
1. We can revert to a static world with no replacement-by-fee mechanism as a widely deployed network policy.
I think in a world where miners are in competition you can always reach out to them with out-of-band higher fees packages than available in their local mempool.
2. We can design, implement and deploy policies to better capture transaction-issuer intent on the way future spend candidates are allowed (or not) to replace the current in-mempool transaction.
Sadly, I think with lightning and other second time-sensitive layers, there is no "single" transaction-issuer intent, though you might have as many intents that you have counterparties within your off-chain states, all with competing interests.
3. We can remove all policy and let the network of nodes and the economic ecosystem evolve on its own.
I think a lot of mempool policy in place is actually anti-DoS measures which are protecting at least the lowest-performance full-nodes, and those measures are the source of issues for pinning. "Pure" RBF sounds to me only to make adversarial replacement issues worse (at least nversion=3-style policy introduces some assumptions on max package size if widely deployed).
4. We can do nothing and let a fragmented mempool environment, where every large lightning and bitcoin business have out-of-band relationships with miners and pools to support their packages, with some service-level safety agreements.
I think this option was weighted as a way to solve pinning issues at the commitment and second-state level years ago by the lightning community, though it was brushed aside as bringing rampant centralization of the lightning network, where small lightning nodes might not have privileged access to miners [0].
5. We can design and implement some magical consensus-change or alter the processing requirements (bandwidth, CPU perf, I/O disk) of full-nodes on the peer-to-peer network to align incentives between miners and lightning and time-sensitive second-layers.
I think this option represents more or less what are the trade-offs of what is discussed by the "reverse locktime" new bitcoin script opcode idea or replacement cache at the mempool-level in core [1].
Best,
Antoine