> See below for an expandable if_in. However, it compares keys with
> \str_if_eq:nn (to be expandable), so that imposes restrictions on
it would indeed. I wouldn't be so concerned about the fact as such given that
we had a time where we required the keys to be tokens or rather csnames but ...
> I feel like it is not a huge restriction for practical applications,
> but I may be wrong. I would say that keys should be stored as is, but
> compared as strings.
one thing that I would find important is that the behavior is consistent, ie
it wouldn't do if
\prop_get:NnN followed by \quark_if_no_value:NTF
can return a different result from \prop_if_in:NnTF
that would be counterintuitive I would say