One solution would be to include the sequence of previous vnums a player has recently been in, in order; a list which slowly gets freed from the bottom forward (as the tracks become too old to follow).
At each step of the mob's tracking algorithm, the hunter goes through this list to find the most recent entry with the vnum that the tracker is in; in other words, if the hunter is in room 1000, it checks the list for the most recent entry of the player being in room 1000. The next item in the list, say 1001, is the room where these tracks lead, hence the direction the hunter should turn.
This has a couple advantages. If the player circles around and crosses her own path, when the hunter comes to this intersection of tracks, they will automatically pick the more recent one, like a real tracker would; but if the hunter somehow gets teleported into that circular part of the path, he does not instantly become lost.
The disadvantage lies in those labyrinthine areas where, for example, room 1000 has more than one exits both leading to 1001. in this case the rules of physics are tossed all about. the player may have gone north (to 1001), but the mob might go south (also to 1001). Whether this makes "physical sense" is a difficult conundrum because this room layout does not make "physical sense" to begin with!
In a case like this, with multiple exits to choose from, the code should be written so our hunter selects the "best" exit-- taking an open, unrestricted path above a closed door above a closed, bashproof, pickproof door, etc.
You might also want to ask yourself whether things like portals should be handled differently. If I were a wizard being hunted, I might hide my tracks by creating a portal whose other end was only 10 feet ahead of me, but by stepping through this tiny warp, it would effectively make a gap in my trail. all things for you to consider.
Of course this method would be very RAM expensive! Would not recommend having those tracks last for any long period of time...