I pasted your test into both the full and LE versions of TCC 13.0.38 on WinXP SP3 and it worked correctly on both systems, displaying " that" (no Win6 available here). I was able to duplicate your report by defining my own @IF function: function if=`4$` - i.e., value is the 4th and all subsequent function parameters (assuming you use the 4NT/TCC default ParameterChar). Immediately I "unfunctioned" IF, and correct operation was restored.
Your second issue does not have a testable example. Just remember, SWITCH has a SINGLE parameter which is a string. @FIELD - if you use non-default field separators - can return multiple strings, or an empty string, either of which causes SWITCH to report an error. Of course, you probably use it correctly.
I too get the same "this, that".
It might depend on the what is used as "comma".
On my system, one thousand is written "1.000,00".
So: "%_WINVER" is "5,2"; "%@eval[%_WINVER - 6]" is "-0,8".
And it is possible that the comma between 0 and 8 is considered as an argument separator.
If I write "echo %@if[%@eval[0,8] ge 6, this, that]" I get " this, that".
If I write "echo %@if[%@eval[0.8] ge 6, this, that]" I get " this".
WAD. You're inserting additional separator characters; there's no way that @IF can predict what is an embedded "ignore-this-it's-not-really-a-delimiter" character and what is a "wait-this-is-really-a-delimiter" character (unless you quote the non-delimiter characters). You need to switch to the DWIM parser!
There aren't many cases where you actually *have* to use @IF instead of IFF / THEN / ELSE.