For those who wonder what all the fuzz in this thread is about, let me try to
explain this with some different terminology, exposing what kind of intuition
these widely diverging value judgements might derive from.
In programming, there are two camps: static typers and dynamic typers. Static
typers want to annotate their programs with information about the objects being
manipulated so the compiler can help them catch careless mistakes even before
the program runs. Dynamic typers don't care about that as much, because they
know they have to write tests anyway (not all programming errors are exposable
as type errors) and these will uncover the same careless mistakes. [The
runtime system will actually check types once the specific context of execution
is available, that's why it's called "dynamic typing".]
The programming debate is beside the point here for a number of reasons*), but
it does shape the thinking of programmers, and it seems in particular it shaped
the thinking of some of the commenters here.
/a/1/b/2 is something that a dynamic typer would come up with. The specific
semantics are well-defined, but only in the specific execution context (what
JSON document this is being applied to).
/a:1/b:2 (to use James' strawman syntax that distinguishes JSON object keys
from array indices) exposes more typing info, so it is more statically typed,
and it will catch mismatches between the types that the JSON pointer assumed to
be present and those that actually are.
For a static-typing fundamentalist, it is viscerally unacceptable to forego the
opportunity of catching this kind of "type error".
For a non-fundamentalist, this is more of an issue of probabilities, and the
interlocking of mechanisms.
Which percentage of usage errors will be caught by this?
Many, many mismatches between JSON pointers and JSON instances to will just not
happen to trigger this particular type error.
So it can be argued that the ability to catch it doesn't really help much: If
you care about mismatch errors, you already need to have something else in
place to catch them -- relying only on the likelihood of a mismatch to trigger
an array/object mismatch would be imprudent. So in reality, the ability to
catch the type error buys you nothing.
(Or, actually, very little, as improved diagnostics is always worth something
in a debugging situation.)
TL;DR: there is no "ambiguity" at all. Please stop referring to an
"ambiguity". There is none.
Just a missed opportunity to catch an error, caused by not sending along
(redundant) type information.
(You will gather that my 2 cents for this change are "not worth it", but I was
more interested in explaining the mere existence of this discussion, first.
Applying the wrong intuitions to an engineering decision is one of the major
causes of suboptimal design...)
Grüße, Carsten
*) Well, for a start, we are not here to catch errors in programming.
Programming languages are difficult because they are the human interface to the
computer's programmability. JSON pointers are a pure machine-to-machine
mechanism, so most of the issues in programming just don't arise. Porting your
intuitions from programming to this is not going to work very well.