Part of the problem is that when comparing values in Mochikit a null or undefined is less than any other value. My expectation is either an exception or trying to make all browsers work the same way (not possible in Safari of course).
Now the result of these arrays were being passed around, in a functional way (which is part of why I liked Mochikit), and a more typical example is the second one given in the bug report:
if (!isUndefined(x)) return x;
Again, IE is creating an extra null object and returns 5 and it returns 4 in Firefox. The actual code using this was getting an exception in IE but not in Firefox because it was trying to treat a null object like an Array.
This is perhaps an example too, where functional passing style was more difficult to debug than if it was in a loop. But then you'd expect arrays to work the same (or at least I did) and that types are maintained (null not being an Array).
Now I'm generating code and allowing commas after each element in a list is a pretty familiar concept in heaps of languages. I can see why Firefox allowed this behaviour. I can also understand Safari following the specification. IE's behaviour though, doesn't make sense to me at all. It seems to have been purposefully created to cause problems.
All of this conspired to take many hours trying to debug code from a very lower level in several libraries, all the way back up to the highest where the arrays were being created.
A good API prevents these kinds of things from being processed - fail fast. I like Safari's behaviour the most - it would've saved me the most time (of course I was on a Windows machine so no help there).