The relevant property is the HTTP semantics of PUT. PUT is designed to be idempotent: repeating the same request against the same resource should establish the same intended resource state rather than repeatedly creating additional side effects. This characteristic makes PUT appropriate when an Until Successful scope might retransmit an operation following a transient failure.

For example, the downstream system might process the initial PUT successfully but the Mule application might experience a network error before receiving the response. Until Successful could therefore invoke the same PUT again. Provided the upstream APIs correctly implement standard PUT semantics, repeating the same modification produces the intended final state rather than duplicating the operation.

Changing PUT to POST would generally make the design less suitable because POST is not inherently idempotent. Executing the operations sequentially changes concurrency but does not itself establish idempotency. Compensating transactions address distributed rollback and consistency when independent operations partially succeed; they are a different reliability concern from idempotent retry behavior.

MuleSoft documents Until Successful as retrying the contained processors until they succeed or retries are exhausted.

Therefore, under the REST/HTTP semantics assumed by the question, no additional Mule processing is required.

Reference topics: Until Successful; idempotent operations; HTTP PUT semantics; reliable retries; Scatter-Gather.

Official documentation: https://docs.mulesoft.com/mule-runtime/latest/until-successful-scope

===============================================================