The logic you'd love to see communicated automatically is too complex. In addition, there are always other reasons (change of mind, drunk operators, ...) that don't fit into this. I, personally, prefer the rating system implemented in lnd-manageJ (see https://github.com/C-Otto/lnd-manageJ/blob/main/rating.md), but that's not the only information I consider.

Wait… doesn’t the channel opener pay for a force close. Did you manually initiate a CPFP? I’m puzzled as to how this could have come from your pocket.

People often say things like, "Satoshi got so much right"--but I think he didn't think through some things, or just assumed that the software would evolve as needed to compensate for scaling issues. Whatever he thought, I'm certain he didn't envision 8 billion people owning their own UTXOs since it would take something like 40 years worth of blocks for that single UTXO claim to process (and that's even with segwit)--and then what? No on-chain system scales by itself--that's the blockchain CAP theorem: Security, Scalability, Decentralization, you get 2/3 onchain, for the 3rd you need a layer 2. Satoshi made the decision that Decentralization and Security were paramount and that Scalability would come later. Some cryptos mistakenly think that Scaling should be one of the 2 on-chain pillars and that's why they will fail, because they sacrificed on-chain Decentralization or Security.

if both nodes run the same policy, it's all just code on both sides... if you trust the other node to uphold the standards you agree on, then it's doable, but there would need to be some additional kind of HTLC type deal if you wanted to be able to punish someone for ignoring the rules (aside from deciding to just close the channel on them). I think the best rules in lightning are things like ZBF where it's just a detectable setting and your node can be highlighted for having that configuration. There's no punishment for changing your mind aside from losing your label on node index sites for being ZBF. Positive re-enforcement through providing value.

more context for the feature: https://github.com/lightningnetwork/lnd/pull/3915

allow-circular-route is disabled by default to prevent a peer from using you to move funds both out and then back into themselves. This doesn't prevent you from circular routing someone's rebalance through multiple hops, just that you wouldn't be the single source of rebalancing. This might not sound like an issue, but it can be part of a type of griefing attack where someone opens a connection to your node, then saturates your pending HTLCs with circular rebalances: https://github.com/lightningnetwork/lnd/issues/3771

IMHO, this is not something most small nodes need to worry about and you might have a valid use-case for doing this between two nodes that you own that are connected to each-other. It would be more useful if this feature were updated to be an allow-list of circular-routing friendly peers (so you could selectively enable this use-case but not allow random connectors to do this).

; If true, our node will allow htlc forwards that arrive and depart on the same
; channel.

But I am still unsure.