Native vs Elisp JSON key serialisation

[Basil L. Contovounesios]

While looking at bug#42545, I noticed some inconsistencies in object key
serialisation between json-encode and json-serialize.

When serialising hash tables:
- json-encode translates the keys 'foo, :foo, and "foo" to "foo"
- json-serialize translates "foo" to "foo"
  (and rejects symbols as keys)

I don't have a problem with this; it makes sense to me that json.c is
stricter, and json.el is older so has more backward compatibility to
maintain.  In other words, the two implementations are sufficiently
consistent IMO.

When serialising alists:
- json-encode translates 'foo, :foo, and "foo" to "foo"
- json-serialize translates 'foo to "foo", and :foo to ":foo"
  (and rejects strings as keys)

Here the two implementations are inconsistent.  Should the older
json-encode also translate :foo to ":foo", or should the newer and more
prominently (in the Elisp manual) documented json-serialize translate
:foo to "foo"?

When serialising plists:
- json-encode translates :foo to "foo" (and interprets 'foo and "foo" as
  starting an array rather than associative object)
- json-serialize translates 'foo and :foo to "foo"
  (and rejects strings as keys)

Here the two implementations are again inconsistent.  Should json-encode
also accept plists with non-keyword symbols as keys, or should
json-serialize accept only keywords as keys?

In both cases, I'm inclined to change json-encode to be more consistent
with json-serialize as the more authoritative of the two.  Either way, I
think the two implementations should be as consistent and thus
interchangeable as possible.  WDYT?

-- 
Basil