The_sussycheese I agree. We already have a pretty good path finder and commands like .goto, .path, and .follow. They just need some tweaks to become a viable Baritone alternative:
.goto needs to be less strict by default. If a position is unreachable, it should by default move as close as possible to it instead of refusing to move at all. This would also make it possible to .goto a far away position where the chunks haven't loaded yet. .path should probably get these changes too.
We are missing some convenience commands like .thisway, .surface, etc.
A setting to allow .goto, etc. to break blocks. This is already used in TreeBot to break leaves, there just isn't a setting for it. Also, mining is currently just a flat 2x cost multiplier, which was good enough for TreeBot but we'll need something more sophisticated to have the pathfinder decide correctly between different blocks (e.g. obsidian vs. stone).
There are quite a few bugs with the current pathfinder / pathprocessor (e.g. getting stuck in vines) that need fixing. It would be great to have automated tests for that since it's a very complex part of the codebase. This will have to wait until I'm done migrating to the Fabric Client GameTest API though.
The current pathfinder can't place scaffolding / temporary blocks. This is what's holding back TreeBot from supporting large oak trees. It would also need the ability to clean up any temp blocks it places (which I think Baritone doesn't do?). This gets complicated fast so I'd much prefer to have automated tests working first.
I think 1. is by far the most important change. The strictness of .goto makes Wurst's pathfinder look far less capable than it actually is. 2. and 3. also make a big difference and are relatively straightforward to implement. 4. and 5. need to wait for better tests.
