Code change:
3.8. <del> A Normalized Path is a JSONPath with restricted syntax that identifies a node by providing a query that results in exactly that node.  For example, the JSONPath expression "$.book[?(@.price<10)]" could select two values with Normalized Paths "$['book'][3]" and "$['book'][5]".  For a given JSON value, there is a one to one correspondence between the value's nodes and the Normalized Paths that identify these nodes.  Note that there is precisely one Normalized Path that identifies each node. A JSONPath implementation may output Normalized Paths instead of, or in addition to, the values identified by these paths. Since bracket notation is more general than dot notation, it is used to construct Normalized Paths.  Single quotes are used to delimit string member names.  This reduces the number of characters that need escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts. </del> <ins> A Normalized Path is a canonical representation of the identity of a node in a value.  Specifically, a Normalized Path is a JSONPath query with restricted syntax (defined below), e.g., "$['book'][3]", which when applied to the value results in a nodelist consisting of just the node identified by the Normalized Path.  Note that a Normalized Path represents the identity of a node .  There is precisely one Normalized Path identifying any particular node in a value. A canonical representation of a nodelist is as a JSON arrays of strings, where the strings are Normalized Paths. Normalized Paths provide a predictable format that simplifies testing and post-processing of nodelists, e.g., to remove duplicate nodes. Normalized Paths are used in this document as result paths in examples. Normalized Paths use the canonical bracket notation, rather than dot notation. Single quotes are used to delimit string member names.  This reduces the number of characters that need escaping when Normalized Paths appear in double quote delimited strings, e.g., in JSON texts. </ins> Certain characters are escaped, in one and only one way; all other characters are unescaped. <del> Normalized Paths are Singular Paths.  Not all Singular Paths are Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </del> <ins> Note: Normalized Paths are Singular Paths, but not all Singular Paths are Normalized Paths.  For example, "$[-3]" is a Singular Path, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </ins> Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not. So the definition of "normal-hexchar" is designed for hex escaping of characters which are not straightforwardly-printable, for example <del> U+000B LINE TABULATION, but for which no standard JSON escape such as "n" is available. </del> <ins> U+000B LINE TABULATION, but for which no standard JSON escape, such as "n", is available. </ins> 3.8.1.

Related discussion:
text: I welcome this ... thanks.
From the side line: Do we need to add description of behavior (with a qualifier) to motivate the truly welcome attributes of the ?
A Normalized Path is just a particular kind of JSONPath query. Its only behaviour is to identify a node within the tree of nodes in a value. Or did you have some other behaviour in mind?
Oh, of course, but that formulation had never occurred to me, and it's useful. If it's not in the spec, it should be.
I meant the first of the two sentences: Here we describe the behavior of an implementation (output as response to an unspecified request that triggers the former). I just wonder if this section is a good place to describe a part of a protocol, when the topics are a) the "projection" itself and b) potential benefits (all from a data perspective).
Well, we describe the nature of what it is to implement JSONPath. Generally, in a protocol, you not only need to prescribe what is on the wire, but also what it means. That is only ever in the implementation. That doesn't mean that it describes the behavior of an implementation. E.g., in TCP, the byte stream that is transported by the protocol only ever happens in the implementation. Nothing on the wire reflects this byte stream. But describing that byte stream as the underlying model of TCP is rightly not criticized as "describing the behavior of an implementation".
The penny has just dropped: you are questioning the need for such a description rather than asking for more of the same! I agree with NAME response.
I think an important aspect that this is missing is that normalized paths are contexted to the JSON data that was queried; whereas singular paths exist independently, as does any other path. For example, the path (used in the text) is singular and can rightfully exist on its own. However it can't be normalized without querying JSON data. Once queried, the resulting normalized paths can be different based on the data. yields a normalized path of for the value yields a normalized path of for the value .
This text isn't getting into implementation behavior at all. It's specifying output and allowing for options.
Well, unforced ambiguous behavior then. Specifying output and allowing for (unrequested) options.