IIRC the GCS filters have:

• no false negatives
• false positives

This is fine for BIP158 blockfilters (the worst that can happen is that you download a block which is not relevant for you).

If I understand this correctly, this can be catastrophic for what you are trying to achieve here, right? False positive will mark the note as spent even though it is unspent.

Or do you suggest to use the filter to identify "surely unspent" (unmatched by GCS) notes and then query only the ones that have been "possibly spent" (all matches by GCS)? This would work. But if that is the case then this is not clear from the text or I missed it.

Or do you suggest to use the filter to identify "surely unspent" (unmatched by GCS) notes and then query only the ones that have been "possibly spent" (all matches by GCS)?

Yes that's the idea. Unmatched notes are surely unspent and matched notes are possibly spent with probability $p = 1 - 1/m$. So the client has to decide whether the FPS is acceptable or query the "possibly spent" ecash for confirmation. This is only meant for client side use, so the Mint still relies on the DB to decide whether to accept notes in the redemption.

@prusnak how would you change it to make it clearer?