This is not so much a bug since it was put in intentionally, that's why I stuck this in "Feature/Change Request".
The basic problem is that ("Bob" == 0) evaluates to TRUE, defying all the logic which I've been raised with. I've tried to add this to the comments section under the documentation for bools, but after an exchange it was reccomended that I submit a Documentation Bug Report instead. I do however believe that this requires the attention of more than just documentation, so I'm submitting it here.
I've been told that the reason ("Bob" == 0) is TRUE is that "Bob" can't be translated into a numeric representation to compare to, and so it is converted to 0. By the logic of other programming languages, I would expect 0 to be converted to a string, not the other way around (I have since modified all my code to ((string)"Bob" === (string)0) ), but I dont think such being different is a bug so I'm not complaining.
The problem is that I dont consider a string that has something in it to be equal to zero. So here's what I propose: Add a new constant "BLEEM" [to borrow from George Carlin], which evaluates as being a number but does not == any number. Any string unable to be converted to a logical number, besides the empty string, will be set to BLEEM, The idea being that a string which is not a number should NEVER evaluate true when asked "Is this string equal to this number?"
This may want to be held off until a major release, since it could potentially break code.