True, there's no real usefulness in having a &binvarname containing a space. Directly related to fixing the $urlget parsing of the &binvar target would likely fix 2 other ways to create &binvarname containing spaces, or where %var and its contents can be interpreted in 3 ways:
1a. $hget creates binvar named "&v text"
//hfree -w foo | hadd -m1 foo item data | echo 4 -a $hget(foo,item,&v text) : $bvar(&v text) vs $bvar(&v) vs $bvar(&v text,0)
1b. $regsubex (and $regsub) creates binvar named "&v text"
//echo -a noop $regsub(foo,test,,,&v text) = 1 = success | echo 4 -a $hget(foo,item,&v text) : exists: $bvar(&v text) not exist: $bvar(&v) size 4: $bvar(&v text,0)
1c. $regsubex and $regsub create %zzyzyx where $var() thinks the varname is %zzyzyx containing 'test data', but /echo thinks that %zzyzyx does not exist, and $len() and $left() think the varname is '%zzyzyx test' containing 'data'
//unset %zzyzyx* | echo -a noop $regsubex(foo,data,,,%zzyzyx test ) | echo 4 -a varname $var(%zzyzyx,1) value $var(%zzyzyx,1).value : name.len $len($var(%zzyzyx,1)) datalen $len($var(%zzyzyx,1).value) :: *$len of content: $len(%zzyzyx test) vs $len(%zzyzyx) content $left(%zzyzyx test,99) vs null: %zzyzyx
The related issue for /hload was suggested here:https://forums.mirc.com/ubbthreads.php/topics/266694/hashtable-item-names-with-spaces
The most common way that hload would be loading itemnames containing spaces would be an error due to not loading in the exact same format used by /hsave, so it might be best to change /hload to have the default behavior of considering an itemname containing a space to be invalid except if using a brand new switchletter.
However, it can be useful to have spaces in a hashtable itemname, such as having filenames be the filename without being forced to use $encode(filename,m) as the itemname, where you're forced to choose between either having filename-strings being case-sensitive or losing the upper/lower by using $encode($upper(filename),m) as the itemname.
Changing spaces to underscores in itemnames is something I'm not so sure i'd be in favor of, since it would create the scenario where itemnames "foo_bar" and "foo bar" would have the contents of whichever is the last one loaded. Hopefully it wouldn't borrow the behavior from DCC where ^ in filenames are also changed to _'s.
The other way to handle hashtable spaces is like I suggested in the other link, with a -q switch indicating to /hadd /hdel /hinc /hdec that an itemname beginning with " should indicate this is a quoted string for the filename.
My suggestion of $urlget was trying to find a way to fix things in a backwards compatible way, where $urlget being different than $getdir would the more secure behavior of having the non-relative no-path-filenames and /relative/filename both being 'related' to the same folder location. A new switch could accomplish the same. By sandboxed, I meant that relative paths without a drive letter wouldn't allow escaping the H: drive so the ..\ shenanigans wouldn't work.
$urlget was also trying to get there to be a way that urlget behaves more like the other /write commands where no-path means the target is in $mircdir. For $urlget I had always been fetching to target &binvars instead of to disk files, so when trying to fix the GPF problem involving /hsave -i, Khaled had created a testing script that was downloading to unique filenames. Since the target contained no relative-path, I thought the file would be downloading to $mircdir, and I was confused because no files were showing up. By the time I figured out that the files were going into $getdir instead, there were over 100,000 files in the downloads folder, and it was a big mess trying to deal with that. So, a $urlget and/or switch would let users decide whether they wanted to point $urlgetdir to $mircdir, or to $getdir, or to create a urlgetfolder/ for them.