I don't think that (name = "value", valuetype="vector") fits very well, here.
There are a few bits of information we'll need down the line:
1) we have an explicit list of element expressions so we'll need a VectorValueExpression to collect them.
The class of AbstractExpression needed is usually/mostly determined by the "name" attribute, (as in name="function", name="operator", etc.) so I'd suggest name="vector"
2) its result is a vector/array/list as opposed to a scalar expression. This is pretty much a given once we've established that it's a VectorValueExpression. It can also be inferred from the fact that it's being used as the rhs of an IN operator. So, it doesn't really
NEED to be reflected in an attribute here.
So if valuetype is even required, it could be valuetype="vector" -- but in any case, I wouldn't use it to drive the decision to construct a VectorValueExpression.
3) it's composed of expressions that must match a particular type. This can be inferred/pushed-down later based on context -- the type of the IN operator's lhs. But arguably, if convenient, it could also be captured in valuetype (with "vector of..." implied by context).

Whatever we do for setting valuetype, I think that it should be consistent between this case and the vector-valued parameter case we introduce for "x in ?". The parameter case would have something DIFFERENT for name -- whether that's "value" (like scalar parameters -- with the context or some other attribute determining the difference) or something new like "vectorparameter".

Actually, in retrospect, I'm not crazy about how we use name="value" for both constants and params, but let's not make it worse.