I'm afraid this statement is wrong: HTLCs get stuck when the node currently processing it stops responding, independently of how the sender and recipient have negotiated the preimage / payment_hash.

What is true is that a part can be re-attempted without having to wait for the HTLC to settle, but only until the last part has been sent. The last part essentially being the XOR of all prior parts, leading to the preimage, and that can't be changed, since now both attempts could end up being claimed, causing the sender to overpay by the amount of that last part. The same is possible with sender-mixins (also called stuckless payments), but without that special case for the last part (each part requires the sender to reveal a secret after the recipient confirms receipt so no guessing if a part has arrived or not, and the sender will refuse to reveal more secrets than necessary to fulfill the payment, i.e., no extra parts that can still confirm).

That's all for the payment process however, the bigger problem is that channels with stuck HTLCs may end up being closed because the refund timeout is approaching. Neither AMP nor stuckless payments do anything for that situation.