Change:
not exist.  Otherwise it is _truthy_, resulting in its value.  To be more specific explicit comparisons are necessary.  This existence test -- as an exception of the general rule -- also <del> works with complex values. </del> <ins> works with structured values. </ins> Regular expression tests can be applied to "string" values only. <del> Containment tests work with arrays and objects. </del> <ins> The value of the first operand ("containable") of a "contain-expr" is compared to every single element of the RHS "container".  In case of a match a selection occurs.  Containment tests -- like comparisons -- are restricted to primitive values.  So even if a structured "containable" value is equal to a certain structured value in "container", no selection is done. The value of the second operand ("container") of a "contain-expr" needs to be resolved to an array.  Otherwise nothing is selected. </ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least

Discussion:
URL
After thinking a while about comparing structured types, I now see no problem to support equality of them. I agree to handling them is straightforward: also see ... not exactly, what we want though. We need to be clear about order ... ! Containables may be defined on exactly that comparison rule. I believe, we need to add objects here again. Also we need to discuss subsets. Once having agreement about handling that edge cases (maybe there are more), we might add it to the spec. Btw.: JavaScript resolves all comparisons above to , since objects are equal only, if they are referencing the same object (no deep equals).
Comments inline. ordering. surprise and so is likely to cause confusion. Also I am not aware of any precedent for such conflation in mathematics or programming language semantics. [1,2] in [[1,2]] // structured value membership Also, we need to discuss ordering of arrays. For example: [1,2] in [[2,1]] should be false, if we agree that [1,2] != [2,1]. I don't think we should conflate membership and subset. Since "in" has a stronger connotation of membership than subset, I don't think we can easily define "in" with an object on the right hand side. Note also that there isn't yet a notation for a mathematical "maplet", but if we represented it as a pair, e.g. ('x',1), then we could test membership of objects thus: ('x',1) in {x:1} (However, I don't think this is worth the cost of increased complexity of the spec.)
I totally support a decision to: not dealing with subsets restrict the rhs to arrays only with contain-expr's.
We decided not to have " in ", so this is now closed/revisit-after-base-done.
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
While this may be a bit premature as long as we don't know what the rhs of contain-expr should be, it is missing its lhs. What is in the container?
Oh, and the same with :
Well ... good point.

Starting with these examples: lhs is restricted to a primitive value (possibly only number and string). lhs holding a complex value will fail, i.e. no selection occurs. rhs must be resolved to a complex value (array or object). rhs holding a simple value will fail, i.e. no selection occurs. Given this we have something like this ... ... as a starting proposal.
(From 2021-09-17 interim:) So we would have syntax for array literals composed of primitive values only (subset of JSON array literals); other JSON array literals cause a syntax error. (Empty array literals should be allowed to simplify code generation.) A LHS evaluating to a complex value would not match. The path on the RHS may also yield an array, we would match against every single element of that like we would match against a literal array. Example: tending towards consensus on: if $.colors is an array of structured values, NAME is a single structured value? only match primitive values from the LHS (counterintuitive!?) = [128, 255, 17] no selection even if = [[128, 255, 17], [1, 2, 3]] (we cannot avoid structured data to turn up in a query, but we don't match) Avoid deep equals! (We already avoid it in simple comparisons.)
Reminder: lhs of ... From to as a proposal.
Fixed in 9da13ab4 (Still needs resolution of to become active.)
Let's merge this so we have a better base for discussion.