Just FYI, mIRC could always optimize a hash table for insertion/deletion if a switch was supplied during creation. This is why I had previously suggested the -i switch in the thread you linked, to tell mIRC to optimize the keys as indexed integer values. Using such a switch, mIRC could collapse/shift indexes during insertion/deletion-- or even just store the internal structure as a pure array for super-duper-efficiency, if Khaled wanted.
Then, why did you emit that idea (in bold) if it's not because you know that's what people want, especially when you know that's the best thing to do for efficiency ? I thought you wanted to keep the hash table syntax for simplicity but that you still wanted a real array internally.
Saying you want -i only for the shifting part because it would allow us to have an array-like way to store data is wrong for two main reasons: that's not the good way to do it (but you know that) and:
The fact remains that most users aren't concerned about the efficiency differences in deleting items in an Array
this is your opinion, not fact, and they might be much more people that would use the real advantages of an array than what you think.
As a last resort, this is how you argued several time in the past so make your choice:
1) I want to see real array implemented with all the efficiency it implies
2) I want to see array implemented using hash table, with all the inefficiency it implies
