Realize that you're using a hashtable here. Hashtables are (classically) unordered data structures. mIRC's implementation is no different. This means that $hget(tabname,N) does not guarantee order-- you will not always get the Nth inserted item. You will get whatever item is hashed at index N.
To explain your results, I imagine mIRC is probably hashing sresult.4, 5, 6, etc. in front of sresult.3 and pushing result.3 to the end of the list, continually making it the last item in your hashtable. $hget(tabname, %i).item will therefore always be sresult.3 when %i is the last index. Again, this depends on the data set you're using and may change drastically if you changed your item names from "sresult" to "results". It may even change when you get to sresult.7 or higher (you don't need to confirm if it does or doesn't, this is just hypothetical).
Long story short: don't access items by their index; even the help file warns against this. It's both inefficient and defeats the purpose of using hash tables. Besides-- you were smart enough to embed an index in the item name, so you can already directly access items by your own logical index: $hget(search.results,$+(sresult.,%i))
