Hi Chris,
You are seeing the behavior as currently implemented. For now, N1QL only offers this guarantee: if there are one or more indexes that can satisfy the query, one of those indexes will be used. For now, N1QL is not guaranteed to use the longest or most selective of those indexes.
In your example, you can stick with only one index, the 3rd one, without any loss in generality or performance.
Finally, JOINs in N1QL only scan the first (leftmost) keyspace, so only indexes on that keyspace are considered. In your example, the “cards” are fetched directly using their keys, so there is no need for a second index scan.
Please lmk if this answers your question.
Thanks,
Gerald