XPath 2.0 has some new functions and syntax, relative to 1.0, that work with sequences. Some of theset don't really add to what the language could already do in 1.0 (with node sets), but they make it easier to express the desired logic in ways that are more readable. This increases the chances of the programmer getting the code correct -- and keeping it that way. For example,

* [`empty(s)`](http://www.w3.org/TR/xpath-functions/#func-empty) is equivalent to `not(s)`, but its intent is much clearer when you want to test whether a sequence is empty.
	+ **Correction**: the [effective boolean value](http://www.w3.org/TR/xpath20/#id-ebv) of a sequence is in general more complicated than that. E.g. `empty((0))` != `not((0))`. This applies to `exists(s)` vs. `s` in a boolean context as well. However, there are domains of `s` where `empty(s)` is equivalent to `not(s)`, so the two could be used interchangeably within those domains. But this goes to show that the use of `empty()` can make a non-trivial difference in making code easier to understand.
* Similarly, [`exists(s)`](http://www.w3.org/TR/xpath-functions/#func-exists) is equivalent to `boolean(s)` that already existed in XPath 1.0 (or just `s` in a boolean context), but again is much clearer about the intent.
* [Quantified expressions](http://www.w3.org/TR/xpath20/#id-quantified-expressions); e.g. "`some $x in` *expression* `satisfies` *test*`($x)`" would be equivalent to `boolean(`*expression*`[`*test*`(.)])` (although the new syntax is more flexible, in that you don't need to worry about losing the context item because you have the variable to refer to it by).
* Similarly, "`every $x in` *expression* `satisfies` *test*`($x)`" would be equivalent to `not(`*expression*`[not(`*test*`(.))])` but is more readable.

These functions and syntax were evidently added at no small cost, solely to serve the goal of writing XPath that is easier to map to how humans think. This implies, as experienced developers know, that understandable code is significantly superior to code that is difficult to understand.

Given all that ... what would be a clear and readable way to write an XPath test expression that asks

> 
> Does value X occur in sequence S?
> 
> 
> 

Some ways to do it: (Note: I used `X` and `S` notation here to indicate the value and the sequence, but I don't mean to imply that these subexpressions are element name tests, nor that they are simple expressions. They could be complicated.)

1. `X = S`: This would be one of the most unreadable, since it requires the reader to
	* think about which of X and S are sequences vs. single values
	* understand general comparisons, which are not obvious from the syntax
		1. However, one advantage of this form is that it allows us to put the [topic](http://en.wikipedia.org/wiki/Topic%E2%80%93comment) (X) before the *comment* ("is a member of S"), which, I think, helps in readability.
		2. See also [CMS's good point](https://stackoverflow.com/a/17253884/423105) about readability, when the syntax or names make the "cardinality" of X and S obvious.
2. `index-of(S, X)`: This one is clear about what's intended as a value and what as a sequence (if you remember the order of arguments to `index-of()`). But it expresses more than we need to: it asks for the index, when all we really want to know is *whether* X occurs in S. This is somewhat misleading to the reader. An experienced developer will figure out what's intended, with some effort and with understanding of the context. But the more we rely on context to understand the intent of each line, the more understanding the code becomes a circular (spiral) and potentially [Sisyphean](http://en.wikipedia.org/wiki/Sisyphus) task! Also, since `index-of()` is designed to return a list of all the indexes of occurrences of X, it could be more expensive than necessary: a smart processor, in order to evaluate `X = S`, wouldn't necessarily have to find all the contents of S, nor enumerate them in order; but for `index-of(S, X)`, correct order would have to be determined, and all contents of S must be compared to X. One other drawback of using `index-of()` is that it's limited to using `eq` for comparison; you can't, for example, use it to ask whether a node is *identical* to any node in a given sequence.
	* **Correction:** This form, used as a conditional test, can result in a runtime error: `Effective boolean value is not defined for a sequence of two or more items starting with a numeric value`. (But at least we won't get *wrong* boolean values, since `index-of()` can't return a zero.) If S can have multiple instances of X, this is another good reason to prefer form 3 or 6.
3. `exists(index-of(X, S))`: makes the intent clearer, and would help the processor eliminate the performance penalty if the processor is smart enough.
4. `some $m in S satisfies $m eq X`: This one is very clear, and matches our intent exactly. It seems long-winded compared to 1, and that in itself can reduce readability. But maybe that's an acceptable price for clarity. Keep in mind that X and S could potentially be complex expressions themselves -- they're not necessarily just variable references. An advantage is that since the `eq` operator is explicit, you can replace it with `is` or any other comparison operator.
5. `S[. eq X]`: clearer than 1, but shares the semantic drawbacks of 2: it computes all members of S that are equal to X. Actually, this could return a false negative (incorrect effective boolean value), if X is falsy. E.g. `(0, 1)[. eq 0]` returns 0 which is falsy, even though `0` occurs in `(0, 1)`.
6. `exists(S[. eq X])`: Clearer than 1, 2, 3, and 5. Not as clear as 4, but shorter. Avoids the drawbacks of 5 (or at least most of them, depending on the processor smarts).

I'm kind of leaning toward the last one, at this point: `exists(S[. eq X])`

What about you... As a developer coming to a complex, unfamiliar XSLT or XQuery or other program that uses XPath 2.0, and wanting to figure out what that program is doing, which would you find easiest to read?

Apologies for the long question. Thanks for reading this far.

**Edit:** I changed `=` to `eq` wherever possible in the above discussion, to make it easier to see where a "value comparison" (as opposed to a general comparison) was intended.