Wow. It does that? Huh. That doesn't seem...correct.
If you take two variables and assign the values of "yes" and "true" to them and do a comparison, does the result come back as true? If so, you may have discovered a language bug and should probably report it to Adobe.
That is an interesting discovery though. What kind of process were you trying to do when you discovered that?
I saw "test1" but not "test2". I'm not sure it's a bug less than it may be an undocumented (and unexpected) behavior. I got the same result when removing the quotation marks from around "true" but removing them from around "yes" threw a "Variable YES is undefined" error. Finally, I also changed the second test to "dog" EQ "dog" and that came back with "test2".
So, what does that suggest? To me, the engine (in my test example CF9) understands the functionality of the presence of the quotes on the left side of the equation. If they're not there it evaluates the left side as a variable value which is appropriate and what we expect and how you see it literally every time save this example. I never see quoted values on the left being evaluated for equality with the right side. However, it does work because the "dog" EQ "dog" example worked (and "dog" EQ "cat" did not).
Where the issue comes in is that you're getting a positive equality result when comparing "yes" EQ "true". By it's behavior with "dog" and how it acts when the quotes are absent on the left side, it SHOULD be comparing one literal string to another literal string with "yes" EQ "true"...but it's not. This is what made me think it might be a language bug.
In the case of the CF server, its order of operations is apparently doing a boolean qualifier before it does a literal string comparison...and that's on the contents of what should be the left side literal string. It's that behavior that I think constitutes a possible language bug as the contents on the LEFT side should be literally interpreted and not boolean equivalent evaluated.
It is not a bug in coldfusion, "yes" and "true" are boolean results and it encapsulate 1 for "yes" and also 1 for "true". it means
<cfif 1 eq "true">
should work for result "yesTrue". yes it is working.
finally yes means 1 and no means 0, in same manner true means 1 and false means 0
While most folks who stop by here are aware of what boolean operators are (clearly explained in a previous post) I think you're maybe missing a point here. You're correct in that "yes" and "true" are treated as boolean RESULTS (aka: right side evaluators) but the issue here stems from a literal string being the left side comparator.
CF, by default it appears, is performing a boolean comparison when the code presented to it is asking the comparison to be made to two literal strings. It's not the values per se that is the issue or that a possible boolean word is being employed as a literal string on the right side of the comparison equation. Those are standard performance situations and even CF beginners get that. The issue here is that a left side string containing a word that CF recognizes as a boolean word automatically trips CF's boolean comparison operation when, if you have two literal strings, it should not.
In short, the literal string "true" is not equal to the literal string "yes"...but CF is telling you it is.