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: They have other uses for selecting specific nodes given a much larger query.
I think the spec needs a statement with a MUST/SHOULD/MAY about supporting these things and a clear suggestion as to what useful purpose they're designed to serve. Otherwise I seriously suggest removing them because to be honest I can't think of a single scenario where I'd use them.
I think they're intended not to be written but consumed. I agree in that I doubt anyone would write out except maybe in the context of a stackoverflow question or something. They'd just use . The point of this, though, is to be able to declare a preferred syntax that implementations should use to identify a known location in a document. It's just saying that we prefer over . (One advantage of using the bracketed syntax for normalization is that any location in a document can be written in this syntax, whereas there are restrictions on the dot syntax.) Again, I think this is most apparent in output when the implementation is returning paths to locations instead of / along with the values.
Another consideration is the spec's definition of nodelist as the output of applying a query: The following statement in the Normalized Paths section: steps into implementation detail. In the rest of the spec we studiously avoid prescribing implementation details. One way to reconcile these would be to put some non-normative text near the start of the spec which talks about implementation options for nodelist. This could then include language such as "If a nodelist is represented as a list JSONPath expressions, these SHOULD be Normalized Paths.". (But would it make sense to use "SHOULD" in non-normative text??)
I don't think that's implementation detail. It's defining what the output may be. We can talk about this in another issue if it concerns you, though.
I would say it's a statement about the representation of the abstract nodelist. A list of Normalized Paths is a string representation. Other possible representations are lists of JSON values in string form, a programming language list of nodes, etc. The choice of representation is an implementation decision. Feel free to raise a separate issue if you'd like to change the current text.
Normalized Paths ... are a concrete string presentation of nodelists (JSON text). are already used in the spec within every example table (Result Paths).