Memcached Idempotent Write Operation for Safe Retries

The goal is to guarantee that a client’s retry of a memcached SET (or ADD/REPLACE) does not result in duplicate writes when the initial request was processed but the response was lost. Memcached treats each write as an independent operation; the Compare‑And‑Swap (CAS) token can prevent overwriting a newer value but does not stop a retry from issuing another identical SET after a network loss. Existing client libraries expose retryAttempts or failureMode settings that automatically resend commands, yet they lack a built‑in mechanism to detect that the prior write succeeded.

Should memcached introduce an idempotent write variant that accepts a client‑provided unique token to suppress duplicate writes? Would adding such an operation require changes to the wire protocol and affect backward compatibility? How would clients generate, renew, and expire these tokens to guarantee uniqueness without coordination overhead?