Accept non-standard JavaScript object notation

JsonParser.Feature.ALLOW_UNQUOTED_FIELD_NAMES already provides for the unquoted JSON element names. I haven't yet noticed any configurations for commas.

I don't think it makes sense to even try for full javascript parsing (except maybe as separate sub-project?). But I am open to suggestion for specific aspects, when there are strong use cases.

By strong what I mean is that ideally no one would ever send any non-standard JSON, period.
And any features that support non-standard alternatives do encourage what I view as bad behavior.
So there has to be something to offset for doing what seems like the Wrong Thing – usually this is to improve interoperability with broken systems that insist on sending JSON-like data.
I am not sure space savings are strong enough motivation: if one wants more compact format, it should be designed as new format; otherwise main benefit of standard formats (interoperability when everyone follows standard) is reduced.

So: if this is request is specifically for allowing one to specify empty JSON Array values, could title and description be reworded to reflect that? And specify expected behavior – my initial guess is that one should receive additional JsonToken.VALUE_NULL elements when there is nothing (except white space) between commas?

And there is the issue of handling the trailing comma.

Yes, maybe it's enough to have just a JsonParser.Feature for the trailing comma (ALLOW_TRAILING_COMMA) and for empty array values (ALLOW_EMPTY_ARRAY_VALUE). At least for me. Now I'm using Mozilla Rhino to parse simple json-like format, not very secure and too heavy.
The problem is legacy or third party systems, which not easy to change.
And yes, the option is required only for the parser, don't do it for the generator to keep it standard.

Just curious... is it possible to make somehow a configurable parser error handling API? So that it would be possible to extend parser by custom-build workarounds for Wrong Things™? How universal could it be?

Wrt additions; I agree, trailing comma is something I have seen, and consider specific problem to resolve. Empty values I am neutral about; but if it is needed, it can be handled.
As usual, my main concern is that there is no measurable overhead at parser level for standard use case – this because low-level parser is heavily profiled, optimized, and seemingly small changes can (alas!) throw JVM/Hotspot off. It usually just means that I need to be careful to measure before/after.

As to configurable handling: one possibility would be to add "error character handler". Question is what such a handler could do (skip character; parse it and more; materialize token(s)?), and how it could interface with parser internals. This could be a way to allow arbitrary extensions; not necessarily easily, but at least make it possible. I think that idea warrants a separate RFE, where we could brainstorm. I actually like the idea if it could be fleshed out; this would specifically allow extension outside of core parser.

Closing this issue, as this new entry at github:

https://github.com/FasterXML/jackson-core/issues/52

seems to cover one aspect that would be relatively easy to handle. And other aspects could be added separately.