As people pointed out, using indexed values for keys does not create an internally ordered structure, though the usage of the hash table API where keys are ordered integers *does* result in an ordered structure for all intensive purposes. On one hand, I see why certain nitpickers might care about the internal implementations that mIRC might use for efficiency. On the other hand, the *majority* of users should not be concerned with implementation, as that's Khaled's job... the fact that you can do: hadd tab 2 item | $hget(tab,2) => item means it's functionality equivalent to an array API, so I don't see the issue from a superficial standpoint.
Was this suggested specifically for efficiency reasons, or for functionality? If it really is an efficiency thing, would this really make a big difference? I doubt the bottleneck is the hash function, and I'd bet there would be no noticeable performance improvement, though benchmarks would be interesting to see.
The most constructive thing I could suggest is to add a switch (-i?) on /hmake to index instead of hash. This would mean keys would need to be numeric but it would allow mIRC to implement the structure internally as an array while keeping the user level API the same. The benefit here would be not having to introduce an equivalent set of commands/identifiers that have the same functional behaiour.
