RE: two json.el bugs

[Drew Adams <drew.adams@oracle.com>]

> > > We can't simply serialize/desterialize alists in key order
> > > because the order is reversed in Emacs. (In Emacs alists,
> > > if there are duplicates, the first one wins,
> > > in JSON the last one wins.)
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > If you're talking about JSON objects then no, no particular
> > meaning or behavior is defined for duplicate fields (keys)
> > in a JSON object.
> > 
> > A given application that handles JSON object is free to
> > act as you say.  And it is free to act otherwise.
> 
> Please see Theresa's initial post why this matters.

It is generally good to preserve the order.  With
that general intention I agree.

What's not true is that "in JSON the last one wins"
when there are duplicates.  JSON itself imposes no
such semantics.

And I question mention of "the standard JS
implementation".  No such thing, AFAIK.

An application can do anything it wants with JSON
data, of course.  In particular, it can if it wants
(but typically would not) depend on the order of
duplicate fields.