Improve support for NULLs in filers when used in **is not** fashion

Let me explain with an example. A table of people has a column “country”: values may be, for example, Italy or UK or any other country and may also be NULL if corresponding country is unavailable / undisclosed. When a user tries to extract people from any country except Italy setting the country filter to is not Italy, the user looses also all the people with NULL as country and this is not what is expected.
I perfectly understand the matter under the hood, but the user usually doesn’t and simply perceives it as broken or misleading.

Hi @unguess_data ,
Could you share some screenshots of your exploration result before and after applying the filters is not?

I’m sorry but It’s not clear to me how could I show you that, for example, a table of 100k items would be supposed to yield 50k items after filtering but just 15k are shown, because the 35k missing are due to counterintuitive handling of NULLs.
It is a fact very easy to verify by your side with mock data and straight forward to understand looking at the generated queries: coming back to my previous example, a filter generates a block like WHERE country <> “Italy” but should be like WHERE (country <> “Italy”) OR (country IS NULL), because UI-side the user expects to retrive all the items that are not “Italy” and NULL is definitely not “Italy”.
Technically speaking the simple block WHERE country <> “Italy” is correct, but since NULLs fail every comparison, the user would not get what expected.
Hope that my further explanation in place of screenshots may help anyway