VariantNode

A value together with where it is — RFC 9535's node: "the pair of a value along with its location within the query argument".

{"items":[{"sku":"a"},{"sku":"b"}]}

  $['items'][0]['sku']   "a"
  $['items'][1]['sku']   "b"

The pairing is the whole point. Everything the engine hands back until now is one half or the other: a key, a projected value, a Variant. A caller that narrowed to a document with $.items[*].sku and then wanted to know which element matched had nowhere to put the answer, so it wrote its own walk — and the walk is where the mistakes are. This type is what a walk can return.

A view, not a copy, on the same terms as a projected row: value borrows the bytes it was built over, so it is valid exactly as long as whatever maps them — a snapshot, a document a caller is holding — is open. Anything kept beyond that must be copied, with Variant.toByteArray. location, by contrast, is an ordinary value and outlives everything.

No equals, deliberately, and this is not a data class. A VariantPath compares structurally and a Variant does not compare at all — it is a reference into a segment — so a generated equals would read as value equality while answering half of one. Compare the halves: the locations directly, and the values through whichever of Variant.toByteArray or Variant.toJsonString the question actually means.