CF9 struct key and variable name problem

Question

Running CF 9 on Linux, the following produces unusual results:
<cfscript>
    a = { '99' = "that", '8X' = "this"};
    writedump(a);
</cfscript>
The dump shows only the keypair with the key '99' and the value 'this'. #a['99']# produces "this". #a['8X']# produces "this" as well. It's as though CF cannot distinguish between the tokens '99' and '8X'. Note that implicit assignment is not implicated:
<cfscript>
    blah['GNQ'] = 'bad struct';
    blah['H02'] = 'worse struct';
</cfscript>
This yields a struct with one member per structcount(), with a key-value pair of GNQ='worse struct', but the key 'H02' accesses the same value. structkeyexists(blah, 'H02') returns true.
On our systems (we've tried CF 9 on separate RH 4 and RH5 machines) the problem is not limited to structs per se, and seems to persist even when other characters are involved in variable or struct key names:
<cfscript>
    testb0 = "test";
    testao = "test2";
</cfscript>
This produces an error page with the message "can't load a null". However, the following is possible:
<cfscript>
    testb0 = "test";
    writeoutput("b0 = #testb0#<br/>");
    writeoutput("ao = #variables['testao']#<br/>");
    writeoutput("#structkeyexists(variables, "testao")#");
</cfscript>
The above produces the output 'test' for the undeclared variable 'testao', and also thinks that variables.testao is in the variables scope, even though it hasn't been declared.
A quick loop or two and we've found that our CF 9 installations cannot distinguish between 340 two letter sequences, in matched pairs, as in the following example:
ao = B0
ap = B1
aq = B2
ar = B3
as = B4
at = B5
au = B6
av = B7
aw = B8
ax = B9
Case does not seem to matter, and as mentioned above, this 'blindness' appears to persist even when the strings are embedded in other strings. E.g., when used as key or variable names, the following are being treated by CF as equal:
slap = slb1
tape = tb1e
apes = b1es
Has anyone else experienced anything like this? Could there be some strange setting that is causing CF to interpret the templates using some otherworldy codepage in which these characters are equivalent? Could there be something wrong with our installation, and/or our OS?
Any hints, confirmation of our findings, and/or refutation of same would be greatly appreciated - we were hoping to move to CF 9 from CF 8 this week, but this is quite a showstopper for us.

Answer 1

I did restart but turns out I fed the updater the zip file (hf900-81860.zip) instead of the jar file (hf900-81860.jar).  Now it returns the correct results, "abc" (not "123").  I also confirmed that this problem was not fixed by "Cumulative Hot Fix 1 for Coldfusion 9".  And, I verified that it fixed the more widespread issue in my application.  Thank you guys!
HotFix (thanks buglug):
http://kb2.adobe.com/cps/825/cpsid_82547.html
Related bugIDs:
81860
81884
82491
Related posts:
http://stackoverflow.com/questions/2164472/bug-in-cf9-values-for-unique-struct-keys-refere nced-and-overwritten-by-other-key