Below we don't specify what the receiver should do if they receive final htlcs for the the payment hash but different amt_to_forward. Maybe send error messages back?
This actuallyseems to be a problem because with this I can easily spam htlcs to all channels wich will never be fulfilled (also by making an incomplete base AMP) creating a dos attack

Never mind saw that you put it to the requirements in line 9xx. Still it is not clear to me how to mitigate dos attacks (but I guess that did attack can also exist without base AMP)

Why do we need that?

In keeping, with "It's OK to be odd" rule, which has the corollary "It's BAD to be even".

BADONION has a specific meaning here, which means "I can't even decode it, so you're getting a message from the prevoius node". This is weaker, so should not have that bit set.

Maybe change to : SHOULD suspend incoming HTLCs with the same payment hash:

My mental model is a single-threaded server, so approximately, you would write code as below:

1. If the incomplete_payment is set, suspend incoming HTLC (also set a timeout trigger to fail suspended HTLCs due to taking too long)
2. Scan through all suspended HTLCs and sum up their total.
3. If the total in all suspended HTLCs >= amt_to_forward, then claim them.

Although the changed wording seems fine to me, either way.

I would leave out this 3rd Paragraph of the 4 added rational paragraphs. I think the other 3 work without this one

It is confusing. We are at the part where the amt_to_forward is different. Now you give an rational when to succeed the htlcs.

I would separate this somehow

They are on the same level, so my mental model is that these rules are evaluated in that order, and this rule is not gated by the amt_to_forward rule.

Let's drop this phrase altogether. "Partial Payments" is better.

Atomic Multipath Payments is how the users know this feature, so I am hesitant to change it.

Which users now this as AMP? When the majority of those that are aware of LN, here "AMP", they think of the original ML post. The only individuals that know of this partial payment feature are those that were at the summit.

Okay, I shall change it then.

"ZKCP-preseerving proper multipath payments"

I don't think we should do this at all. Just let the recipient send a receipt when they have >= expected amount.

I have come to agree.

Let's rework this to be clear:

The payer:
  - if `wait_on_incomplete` is not set in the invoice:
    - MUST NOT set the `incomplete_payment` flag.
  - otherwise:
    - If they split the payment into multiple HTLCs:
     - MUST use the same `payment_preimage` on all HTLCs.
     - MUST set the `incomplete_payment` flag on all HTLC onions.
     - MUST ensure that the total amount of all the HTLCs at the payee meets the `amount` requirement of the invoice.
     - SHOULD send all payments at approximately the same time.
     - SHOULD try to use diverse paths to the recipient for each HTLC.
     - SHOULD retry and/or re-divide HTLCs which fail.
     - MUST NOT allow the total value of active HTLCs to exceed the amount it is prepared to pay.

The payee:
  - if an onion with `incomplete_payment` is set for an invoice which flagged `wait_on_incomplete`:
    - MUST not immediately fail the HTLC if it is valid except for the amount being too small.
    - SHOULD wait for at least 60 seconds for more partial payments for the same `payment_preimage`.
    - MUST accept all partial payments once the total amount meets or exceeds the invoice `amount`.
    - MUST reply with `incomplete_payment_too_slow` to all partial payments which it times out.

BADONION has a specific meaning here, which means "I can't even decode it, so you're getting a message from the prevoius node". This is weaker, so should not have that bit set.