To answer your question, you write a new IExplorer, and then replace the instances of the "GridExplorer" type with your explorer in the Default code. IExplorer doesn't support easy type switching like PlayerMover or Routines, because there's no reason to change it. It's for one very specific, basic purpose, and if you want it to do anything other than that, you don't need it in the first place, as you'd not be using the explorer related task but rather your own task and explorer instance to run logic instead.
One of the plugins I wanted to make for a while is an explore visualization tool to help people understand what GridExplorer actually does, and why you don't need to modify it or even think about replacing it to solve issues such as backtracking or optimal map grinding. I think it'd be easier to understand that way than me trying to write a massive reply explaining why things don't work the way you think they do.
But, consider this, it's possible to fully explore and clear a map without GridExplorer ever running once to tell the bot where to go. That's the inherent problem with the idea of trying to change GridExplorer to avoid backtracking. Any back tracking issues caused by GridExplorer are unavoidable because inherently to the current design of things:
1. GridExplorer doesn't care about the layout of an area; it's a virtual grid aligned to the tile size of the game.
2. Exploration logic does not drive the bot; it simply gives the bot a new location to go when it has nothing else to do.
3. GridExplorer is a self-propelled design that avoids the significant overhead of trying to pre-process an entire area to determine an exploration path, and works under any situation no matter how complex the terrain is with sub-areas (because it's self-propelled).
4. There's only 1 case where modifying the logic of how GridExplorer finds the next location to explore to would matter when avoiding backtracking, but that case is infeasible: if the area had no monsters, no chests, no items, nothing to interact with, and you literally just wanted to explore the entire map as fast as possible. In that case, you could probably write area-specific logic improvements that would help, but what's the point if this isn't a PoE specific case?
Basically, any time you would try to spend messing with GridExplorer won't lead you to anything meaningful, because it's not the root cause of backtracking. You can write your own exploration task or other bot driving tasks that runs before the bot's GridExplorer task if you think you have an algorithm or way to make map exploration better for certain areas, but you don't need to touch GridExplorer to do that. It is possible to write something better using more terrain data and processing pathfinding data, but it's just not worth it for random terrain and the way this game works. I include the source in the Help folder to try and help people realize why they don't understand how things are setup, and what the bot is actually doing compared to what they think it is doing.
As _Grumpy_ mentioned, tweaking settings is probably the better way to avoid the issues you want, but you'll always have backtracking in a game like this unless you're willing to ignore a lot of objects and write logic that skips most of an area.
