There is not really any compelling reason to change the way it works at the moment.

The rules are simple and easy to follow, and of course without changing them they are backwards compatible in all cases [Smile]

Switching the rules to raising the expression to the highest type of the pair is not likely to reduce the number of times a cast (CINT(), CDBL(), CSTR(), VAL()) will be required to ensure that an expression will return the correct type, it just reduces the number of time it may be required for float expressions.

Strings will be particularly vulnerable. It is very common to append a numeric suffix to a string variable, such as
code:
$Filename=$Filename + $Sequence
Which will either cause $Filename to be converted to a numeric type with the type and value of $Sequence.

Of course the rule could apply to numeric types only, and not unassigned, string or other types. The drawback is this creates "special cases" - something to be avoided.

The string confusion could also be resolved by introducing an explicit catenate operator such as "." or ":". (Actually, I think that would be a good move anyway)

Casting both operators (and the result) to the highest type is not a bad thing, but it will break existing scripts, may complicate the rule and doesn't improve the KiXtart language.