Error in cltv_expiry_delta setting?

[JohnLaw2]

The cltv_expiry_delta Selection section of the Bolt #2 spec includes 7 itemized points that lead to the conclusion that the cltv_expiry_delta parameter should be set to 3R+2G+2S.
I believe this is incorrect and that the correct value is 4R+2G+4S.
The most significant issue is in counting the number of instances of the S parameter that are needed.

In the Bolt #2 spec, step 1 states that "B or C commits to the blockchain, and B spends HTLC, which takes S blocks to be included."
Step 2 then states that "C wins the race (just) and fulfills the HTLC, B only sees that transaction when it sees block N+G+S+1."
However, this ignores the possibility that:

• At N+G, both:
  • B submits his Commitment transaction and his HTLC-timeout transaction that spends the HTLC output in his Commitment transaction, and
  • C submits her Commitment transaction (only). [Note: While this behavior is not expected from C, it needs to be tolerated by B.]
• At N+G+S, B sees that C's Commitment transaction won the race and is in the blockchain, at which point both:
  • B submits his transaction that spends the HTLC output in C's Commitment transaction (thus attempting to time out the HTLC), and
  • C submits her HTLC-success transaction that spends the same HTLC output in her Commitment transaction.
• At N+G+S+S, B sees that C's HTLC-success transaction won the race and is in the blockchain, at which point B learns the payment preimage (which is S later than is calculated in the Bolt Pick a licence for the specs #2 spec).

A similar issue exists with steps 4 and 5 in the Bolt #2 spec.
Step 4 states that "B waits G more blocks before giving up waiting for A. A or B commits to the blockchain."
Step 5 then states that "B sees A's commitment transaction in block N+G+S+R+G+1 [which is G+1 after B learns the payment preimage in Step 3] and has to spend the HTLC output, which takes S blocks to be mined."
Thus, Bolt #2 calculates the worst-case time from when B learns the payment preimage to when B spends the HTLC output to be G+S (plus reorgs and provisions for reorgs).
However, this ignores the possibility that:

• After waiting G blocks before giving up on A, both:
  • B submits his Commitment transaction and his HTLC-success transaction that spends the HTLC output in his Commitment transaction, and
  • A submits her Commitment transaction (only). [Note: While this behavior is not expected from A, it needs to be tolerated by B.]
• Then, S blocks later, B sees that A's Commitment transaction won the race and is in the blockchain, at which point:
  • B submits his transaction that spends the HTLC output in A's Commitment transaction.
• Then, S blocks later, B's transaction that spends the HTLC output in A's Commitment transaction is in the blockchain (which is another S later than is calculated in the Bolt Pick a licence for the specs #2 spec).

Please let me know if I've made an incorrect assumption or missed something in this analysis.
In particular, is there an assumption that in step 1 B submits both his HTLC-timeout transaction that spends the HTLC-output in his Commitment transaction and his transaction that attempts to time out the HTLC output in C's Commitment transaction? If so, his transaction that attempts to time out the HTLC output in C's Commitment transaction would be an orphan in B's mempool, which does not seem to be allowed given the description in bitcoin_txmempool.h.

Of course, there could also be blockchain reorgs, and I believe this adds 4R (rather than 3R) to the setting of the cltv_expiry_delta parameter, but that is a less critical issue (as R is smaller than S and the requirement to include R blocks for a reorg whenever a transaction appears in the blockchain is quite pessimistic, as is noted in the Bolt #2 spec).

Similarly, I believe the correct formula for min_final_cltv_expiry is G+2R+2S and for fulfillment_deadline is 2R+2S.