Code change:
This is a draft for us to contemplate and update to see if we can reach a satisfactory clarification.
Thinking about the discussion in and the current definitions ... leads me to the question, why object members can't be nodes. Consider a subtile modification of definitions: Member: A name/value pair in an object. Element: An index/value pair in an array. Node: A pair of a value along with its nodename (member name or element index). Root Node: The unique node with the name "$" whose value is the entire argument. Location: The unique path from the root node to a single node, manifested as a normalized path. This is an alternative node representation, i.e, in nodelists. This way confusing formulations like become obsolete. We also get a more simplified definition for children and anchestors equivalent to child nodes and anchestor nodes. It seems to be consistent to that . Is there something I am overlooking?
We could do this, but that would mean our data model no longer maps to JSON, which doesn't have free-floating members (or elements in the above definition). Also, from a practical point of view, one usually wants to look at a node in the sense we currently have it, not as a combination of the edge leading into it and the vertex itself (in graph theory, node also is usually a synonym to a vertex, not that combination). (I think we already got rid of the confusing wordings.)
That definition of node would not uniquely identify a value in the JSON tree. For instance, in the JSON: the above definition of node says there are two nodes with the value 1 and the nodename 0. This isn't a node, according to the above definition, because it does not have a nodename. In the above JSON example, the Normalized Paths and both point at a single node (with value 1 and the nodename 0). Also, following on from NAME comment, the whole point of JSONPath is to select/extract JSON values from a JSON value, so that rules out selecting/extracting object members, since these are not JSON values.
I am not quite convinced yet. Hmm ... where is it specified, that a node definition must be unique. Nodes in an XML DOM tree aren't either. Object members have an explicit nodename. Array elements and the root node have implicit node names (index and '$'). With our current definition members/elements and nodes are seemingly total unrelated. So maybe we can get completely rid of the term 'node' with its abstract definition then.
That was a somewhat simplified statement. We do have a use for normalized paths, which identify nodes.
The consequences of a node not being unique in a tree include: Outputting a nodelist from a query would not be so useful because it would be missing location information. Converting a nodelist into an array of Normalized Paths would be tricky as the nodelist wouldn't define the order of duplicate entries. A node could have multiple parents, so the tree would't be a tree any more, it would be a directed acyclic graph. Not sure I follow. Object members are not values, do not have nodes, and so don't need a nodename. I don't think that's true. Each member has a value with a node. Each element has a node. Perhaps the ("JSON Values as Trees of Nodes") in PR makes things clearer? I don't think that's possible without introducing a synonym for "node".
I think this should be clear now in the draft -- can we close this?
2023-01-10 Interim: Yes, we can close.

Related discussion:
text: Additional terms used in this specification are defined below. <ins> 1.1.1. This specification models the argument as a tree of JSON values, each with its own node.  A node is either the root node or one of its descendants. This specification models the result of applying a query to the argument as a nodelist (a list of nodes). So nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values. Member names and members (name/value pairs) cannot be selected.  So member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not. </ins> 1.2. This section is informative.