RFC4627 §2.2 ¶1

> The names within an object SHOULD be unique.

RFC2119 §3

> [SHOULD], or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Not allowing duplicate keys in JSON objects is very close the exact opposite of a gotcha. Allowing and round-tripping them would be a gotcha.

No, it can be a gotcha because the json column type (which still exists and many may mistakenly use instead of the jsonb type) allows it:

select '{"foo": 1, "foo": 2}'::json; json ---------------------- {"foo": 1, "foo": 2} (1 row)

select '{"foo": 1, "foo": 2}'::jsonb; jsonb ------------ {"foo": 2} (1 row)

So technically, the gotcha is you have to remember to use jsonb instead of json, as well as json having a true "gotcha" and jsonb not having one.

the json type just stores the string value passed to it, but only the final value is available to the JSON-aware operators.

  mydb=# select
      ('{"foo": 1, "foo": 2}'::jsonb)->'foo' jsonb_foo,
      ('{"foo": 1, "foo": 2}'::json)->'foo'  json_foo;
  jsonb_foo|2
  json_foo|2

Most implementations that allow them, from those I've seen only take the last (in actual order) value...

I would have been worried if it was allowed. This is exactly what arrays are for.

Okay, I'll bite.

What, exactly, do you think should happen if you have an object of the form

    { task: "do stuff", task: "do other stuff" }

? Objects in JSON are key-value pairs. A single key goes to a single value. Instead, you should map task to an array of values.

Um, I think you're agreeing. "Instead, you [i.e., not the deserializer] should map task to an array of values."