Update:

Though $hget could benefit from $hget(string).name to force it to always "Returns name of a hash table if it exists", the other $hget syntax doesn't handle numeric tablenames gracefully. While /hdel and /hadd correctly add and remove items from numeric tables, and /hfree 2 deletes the table named 2, the other hashtable identifiers do not handle numeric tablenames correctly.

Now:

$hget(2,1).item = 1st item of whatever is the 2nd tablename
$hget(2,string) = value of itemname=string in whatever is the 2nd tablename

$hget(0,1).item = ignores the 2nd parm and the .item property and always returns the number of tables
$hget(0,string) = ditto

//echo -a $hfind(2,*,0,w,echo -a $1) = lists all the items in whatever is the 2nd tablename

--

These identifiers could be handled by giving $hget an extra parm for switches that would force the 1st parm to be seen as a tablename, and giving the existing $hfind switch list an extra parm.

Assuming the new switch an arbitrary 'X'

For numeric tablename '2', it would still need .name to check for the table's existence, because $hget(2,X) would crash with current syntax which gets the value of itemname=X from the 2nd table in the list.

However $hget(2,itemname,X) could get the value of itemname from tablename=2, and $hget(0,itemname,X) would then look at the numeric tablename too. Or, instead of $hget(2).name to see if tablename=2 exists, it could avoid a new properity $hget(2).name when parm2 exists as null, $hget(2,,X) instead of adding $hget(2).name

The only problem I can see for $hget is that since existing syntax currently uses the 3rd parm only to hold the name of a &binvar, it would need to assume that parm3 beginning with & does not hold any switches so there would be no support for loading a &binvar from a numeric table - or else the switches would need to be in parm4.

--

For $hfind, $hfind(2,*,0,wX,echo -a $1) would force the 1st parm to be seen as a tablename.

Since $hfind already has the 'n' switch which behaves the same regardless whether using 'n' or 'N', maybe the new switch would be something like 't' that could be used with the same meaning for both identifiers?