Ambiguous duplicate‑key resolution when applying JSON Merge Patch

Goal: determine how a JSON Merge Patch should handle duplicate member names in the target document during a zero‑downtime format migration of a small application.

Constraint: RFC 7386 leaves the behavior undefined when the target contains duplicate keys, and popular libraries (Jackson, Gson, json‑cpp) may keep the last occurrence but this is not guaranteed across implementations, creating uncertainty about which value survives the patch.

Questions: Which value for a duplicated key is retained after the merge patch is applied? How can developers ensure consistent duplicate‑key resolution across different JSON libraries without introducing downtime? Should input be pre‑normalized to eliminate duplicates before patching, and if so, what validation guarantees are needed?