Filter syntax not evident

See my edit above for the background of my problem.

I have to say that I give up; I had intended to use mp3tag as step 2 of my workflow, for filtering, but it becomes way too complicated now. I just read one column in step 1 into an array, then the other column in step 1 into the next dimension of the same array, then filter the array, all in AutoHotkey, then do the (manual, as intended in mp3tag) folder renames from the filtered subset in there.

If it's considered "wrong" that the Filename column contains complete filenames, or if it's considered "wrong" that it contains naked filenames, then, considering that my columns contain 3 types of data in the 2 columns:

. name.suffix = name.suffix
. name.suffix != name.suffix
. name.suffix != name
. there is no data of "name = name" (both without suffix) which would have been the fourth alternative here

then it becomes evident that at least one of my tries "IS 1", or "IS 0", should have provided some subset, be it a tiny subset, or then a very big subset (4 alternatives here), but ANY subset (even a wrong / partly wrong one) - whilst, as said, IS 1 and IS 0 always either provided the whole set, or an empty set.

So, mp3tag trying to do "smart" things behind the scenes, instead of just treating the column data "as is" (it should have done so either for the name.wav entries, or for the justname entries, without the .wav part, but provides no subset whatsoever), I have no chance with my not-yet "normalized" data, and I have to give up on mp3tag: I can not "normalize" my data before treating it with mp3tag, I had intended to use it to help me to normalize it, manually.

Every time I try to use mp3tag (because of its overwhelming good word of mouth in the web), I just lose several (this time) / many (last time) hours. All the more so since this time, the necessary code for comparing / differing within step 1, I already have it at hand (since written for another task in there).

(Btw, I would expect that the nakedfilename, suffix, completefilename is not stored one by one within the file metadata, but that in there is just filename, with the software then making the derived info available, upon request, in two more, "virtual", columns... which implies the question if the software at hand then automatically updates all three, upon manual editing (which in mp3tag cannot be done within the grid, as said), and in both directions.)

You do not react to any of our suggestions like

Yes that is exactly the case if you compare apples with pears.
Your assumption

is simply not correct as you do not take the correct variables.
The filter expression itself returns the correct results only that these results are not what you expected.
Just to cut this short: you have all the tools at hand with checking the column definition, the correct syntax the suggestions of how to modify your initial filter expression.
It is now up to you to continue as you have the problem, not me.
You would have to let go the assumption that the label of a column is also the internal name of the referenced property.
As you are not really co-operative and supply the requested screenshots of configuration data and also do not even try the suggested modifications I see the block for a progress more on your side than in MP3tag's functions.
MP3tag's

is still justified in a lot of cases. It requires a learning curve that some users are not willing to go through.

These steps are all not necessary, if you just use the given Format string in the Filter:
"$if($eql(%_filename_ext%,%title%),1,0)" IS 1

@ohrenkino and I tried several times to explain why this is necessary in your case with the extension .wav in the TITLE.

This is not true. Mp3tag just show the content of the values you have set in the column definition. There is no "kind of magic behind the scenes".