I think that in this context, you constrain the found set to records that have a duplicate value matching records in the entire table instead of just that within the found set. Don't think FileMaker techs would call this a bug, but that's often simply a matter of opinion...
So, because of this bug, there is no way to effectively search for duplicates WITHIN the current found set that you are looking at.
You can sort your records by this field. Then records with duplicate values in the found set will be located adjacent to each other and this is a situation you can use to constrain your found set to just those records with a duplicate value if you use a script to do so...
I would have to agree with scotty321, this seems like a bad behavior on FileMaker's part. When contraining a found set, wouldn't you expect to contrain your found set. regardless of the search criteria entered? Maybe the "!" operator shouldn't be allowed in contraints in order to avoid this confustion? Or better yet, allow users to check for duplicates within a found set!
The duplicate symbol is a cool function but it do not either satisfy me at 100%, and that for one more reason : multiple [!] criterias in same request.
Here too, the usual AND logic is not applied ! A basic exemple is when First Name, Last Name and Address must both be similar to consider records as duplicates. You are thinking that you can just type [!] on both field but... that fails. Because they are considerated separately like in an OR logic in multiple requests.
That brought me to think that a better way (but yes that needs a little more work) is to deal with a dedicated T.O. that is relating orginals and duplicated.
I suppose that you also had thinked about it. But If not, i am developing now a database where i use this technique and bring it rather far. That proves very reliable and comfortable for enduser to see quickly and at any time where are the duplicates of a specific record and for developer too, thus he can provide advanced duplicates-solving scripts !