��� An object is an UNORDERED set of name/value pairs.
Or look at ECMA-404, which json.org points to.
The JSON syntax does not impose any restrictions on
the strings used as names ... and DOES NOT ASSIGN
ANY SIGNIFICANCE TO THE ORDERING.
When you say that "it is pretty clear that the order is
important for that format" I fail to understand you.
It is absolutely clear that by design the order is NOT
important or even significant for JSON.
JSON Pointer does not provide any way to refer to order
in an "object": /2 applied to an object will look for
the name "2" as a string.
JSONPath does not provide any way to refer to order in
an "object": [2] applied to an object will look for
the name "2" as a string.
JSON Schema does not provide any way to constrain or
refer to order in an "object".
As for databases, Postgres documentation says of JSONB
that "Insignificant whitespace is discarded, and
the order of object keys is not preserved."
If you are communicating with someone else who is using
pseudo-JSON that does attach semantics to the order of
the name/value pairs, then of course you do whatever you
have to in order to communicate successfully. Just don't
think of it as JSON. If you have two programs whose
protocol you control, again you can use JSON syntax with
different semantics all you want. Just don't think of it
as JSON. Heck, if it is important to you to distinguish
between integer 1 and floating point 1.0, you can add
your own semantics if you like, but *JSON* doesn't
distinguish them.
As for MongoDB, it works with BSON (which is richer than
JSON. which is why "MongoDB Extended JSON exists), and
does some seriously odd things, like regarding
{} and {"a": null} as equal. (According to the 3.6 manual.)
Do whatever you have to do to get the job done,
but just remember that most JSON tools think they are
dealing with *JSON*, not something else that looks
like it but has different semantics, and can be relied
on to preserve or respect *JSON* semantics, not some
other semantics unknown to them.