Well, I wasn't going to comment here, because I'm neutral regarding the original suggestion. Things got ridiculous now though.
First, in terms of both performance and complexity, you're just wrong. With this feature, mIRC would have to build the index itself, and mIRC then basically has three choices: 1) build a separate index with index reuse, which would make adding items to the hash table more expensive (with O(n) complexity) even when this feature isn't used, or, 2) build a separate index with autoincrement, which would probably have to be a tree structure (with O(log n) complexity) just like in a basic real database, 3) use the memory "cell" as index value, which means mIRC has to validate references given in $hget so as to avoid allowing anyone to crash mIRC with a bad index, and such reference validation would likely.. use an additional hashtable. In none of these cases is the index guaranteed to be faster than the original hashtable. In every case will this take way more than 20 lines of C code to implement.
Second, this feature can be emulated in scripts with an additional hashtable that does reverse mapping. This comes at the cost of roughly doubling the memory needed for all your key strings. For scripters that actually care about this, it really won't be hard to script such functionality, and I say this from experience. Rephrasing the first and second point: your feature suggestion saves memory and does nothing else. Your suggestion might still be useful for certain scripts, but its applicability is limited by nature.
Third, I'm going to assume you didn't really intend to say that hashtables are useless without your feature suggestion, because that suggests that you don't really understand hashtables to begin with.
