/hcopy would be more useful than /hrename. But to say that using variables to solve this problem is "bad", is, well, wrong.

There is no such convention in mIRC that global variables are wrong. They are pretty much the only state of being. I've never heard "use a hash table instead" for single value strings. I think you are referring to the recommendation that large data sets should be stored in hash tables rather than tokenized in strings, which is correct, but a very different problem set than this issue. There's still nothing wrong with storing the hash table name of that large data set in a variable, and in this case, it's the right way to do it, /hrename or not.

As for your point about ensuring the hash table is loaded, that is solvable too (and already something that needs solving without this feature suggestion). You can reset the hash table and the variable name if neither exist-- that only needs a very small addition of a /init.table call (which conditionally creates/loads the table) in the /find.table of my above snippet. This is not a circular problem, they are mutually exclusive checks.

Code:
alias -l find.table {
  if (%myscript.tablename) return
  var %i = $hget(0)
  while (%i > 0) {
    if (myscript.tableprefix.* iswm $hget(%i)) {
      set %myscript.tablename $hget(%i)
      return
    }
    dec %i
  }

  ; haven't returned, so table does not exist.
  ; create or load it from disk
  hmake myscript.tableprefix.0 100 
  set %myscript.tablename myscript.tableprefix.0
}

; ...

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"