Quote:
It still doesn't seem right to me


If everything worked the way the you assumed then you would find life very boring \:\)

 Quote:
...I can't suggest an alternative for the KiXtart interpreter except for explicitly checking for this case


There is no need to change the interpreter - you already have the ability to determine how expressions of different types are handled, including in this specific case. Like programming in any language you just need to know the rules and if you don't like the implicit handling you code explicit handling to deal with it.

KiXtart is a loosely-typed language and it's handling of different typed data reflects this. As you get exposed to other scripting / coding languages you will find that it is far from unique.

If you think beyond your initial post you will see that it has wider implications. Take this expression:
 Code:
$a = "12" + 3
$b = 12 + "3"

What should the value of the variables be? 15 or "123"?

What should happen here:
 Quote:
$a=""
$b=123
$a=Left($b,1)

Should $a=3 (numeric) or "3" (string) or "" (because $b is not a string) or should the script abort with an error because of mismatched data types?

Even "strongly" typed languages such as C will change mixed data types in expressions and leave you scratching your head in confusion at the result if you do not fully understand the rules.

This is a long way of saying that all coding languages have their idiosyncracies and each time you learn a new coding language you need to also learn its idiosyncracies if you want to code accurately and efficiently.

KiXtart's USP is the easy and elegant coding that features such as the automatic variable type coersion / casting allow.