The easiest way to explain this is through an example.
Here is the test data:
Folder Name: "One" Metadata: RecID: "1111"; Status: "Open" Folder Name: "Two" Metadata: RecID: "1111"; Status: "Closed" Folder Name: "Three" Metadata: RecID: "1111"; Status: "" (never set)
These are the search strings and results:
Search #1: {[]:[RecID]="1111"}&{LF:Name="*",Type="F"} Search #1 Result: One Two Three
The above is a simple search and works as expected.
Search #2: {[]:[RecID]="1111"}&{LF:Name="*",Type="F"}&{[]:[Status]<>"Closed"} Search #2 Result: One
Notice that "Three" is missing, even though it meets the search criteria. My assumption is that when the metadata field was never populated (either is null or doesn't exist, depending upon the internal structure) the search test fails and is treated as a false. While this may make technical sense, it's not what a user would typically expect if they were just trying to filter out records with a 'Closed' status.
I did, however, come up with a workaround:
Search #3: {[]:[RecID]="1111"}&{LF:Name="*",Type="F"}&({[]:[Status]<>"Closed"}|{[]:[Status]=""}) Search #3 Result: One Three
I'm posting this since I believe this behavior should be considered a bug in the search logic, as well as to hopefully save others some needless frustration if they run into the same issue.