I don't disagree that /hrename would help in general, but it definitely sounds like you can avoid having to rename your hash table. Or, put another way-- I don't see why you should ever need to rename a table. Just name it what you want from the start.
From what I understand of the very short use case explanation, you're opening a bunch of sockets, writing results to a temp table, and then, when finalizing, you rename the table to something else. I don't see why you have to rename the table to something else.
You're calling the hash table "temporary", but it's not. The hash table and all of its data are "permanent". The only temporary thing about the use case you described is the name you gave it. But again, there's no reason for the name to be temporary. You can make the name permanent.
I assume you're trying to do something similar to a file swap:
1. A <- main hash table
2. create table B
3. write to B
4. delete A
5. rename B -> A
If this is true, you're using the actual table name "A" as a symbolic pointer to "the current table", which is certainly one way to do it -- let's call this "Method A". You're using the hardcoded table named A as if it were a "variable table"; a table that could have any contents. But, that's not how hash tables work, and, more importantly, there is already a way to express "variable" things in mIRC.
Quite simply, you should flip the way you're keeping track of "the current table". Instead of making sure your $hget() always go to hardcoded table A, do lookups through a table whose name is stored in a %variable. Then, all you need to do is update the variable name to point to your new table and you're done. No renames needed.
This has the added benefits of allowing you to do lookups across multiple tables (you don't need to delete the old one), and also, you can rollback fairly easily (again, don't delete old table, just keep it around). In threaded environments (not mIRC) the update is also atomic, so no critical sections needed. In those threaded environments, you can even delete the table in the background, which would create less of a stop-the-world effect. None of this is likely necessary for your use case, but what I'm getting at is that "Method A" is really never a good architecture unless you have some kind of open handle on the table that can stay open across renames-- but mIRC does not support this on hash tables, so it's not a concern.
Basically, what you should be doing is:
1. %A <- main hash table variable name
2. create table ANYTHING_YOU_WANT.tmpNNNNN
3. write to table ANYTHING_YOU_WANT.tmpNNNN
4. /set %A ANYTHING_YOU_WANT.tmpNNNN
5. [optional] delete old table (previous value for %A)
Note: NNNN can be a timestamp, so if you kept old tables around, you could even use the table name as a incrementing version to know which is the latest and even when they were created. You could do this part in other ways, of course, but all this comes for free.
But there you go, no renaming needed. I'm sure I might have some details wrong about your use case, but I'm fairly certain you can follow the spirit of this guide and make your use case work without needing to rename the table.
All this to say that while I think /hrename could be useful as a manual maintenance command, there's no reason to need it in any automated script. There are ways to deal with the constraint of immutable hash table names.
