(I didn't check the includes)

Points of content:

• Moving logic from the/a pathfinder to the caller of the pathfinder. If you want to remove the logic of pathfinder1 in pathfinder2, move it to some meta-pathfinder that controls both.
• Pointers vs. non-pointers.
• A ranged loop.

I don't raise a concern because I am not aware of a hard defect in the code, but this shall not bias that I won't raise one in the future as

• the claimed purpose in the commit message is in doubt
• the review / alternative explanation stage should have mentioned why moving logic from the pathfinder to the caller of the pathfinder is a cleanup and not a cleanliness regression.

And again, please write commit messages carefully and avoid phrases such as:

• didn't particularly make sense and resulted in some interface awkwardness. - the commit message shall inform, "doesnt make sense" and "awkwardness" is not an information
• Decouple long and hierarchical pathfinders to an extent - what is the extent? (I don't ask because I want to know the answer, but the commit messages shall be written in such a way that it's clear what is meant)

There is a simple, infaillible logic to making the hierarchical pathfinder not a sub-class of the long-range pathfinder: you can perfectly use the hierarchical pathfinder without a long-range pathfinder (the reverse isn't true).
If anything, we could make the hierarchical pathfinder own the long-range pathfinder, but the opposite didn't make sense.

I agree that it introduces some regrettable duplication of code, in the AI particularly, but I don't think it introduces too much danger, as these functions are always updated right next to one another.
Furthermore, I question why the long-range pathfinder keeps a grid itself since it doesn't particularly belong there, so these calls might be removed. The AI, also, might not need its own long-range pathfinder or hierarchical pathfinder if it allowed async calls.

Finally, I would suggest deleting this entirely, but that's a separate concern.

There us another argument for making the hierarchical pathfinder a member of the pathfinder: to expose functions form the hierarchical pathfinder, one used to have to write:

• ICmpPathfinder interface
• CCmpPathfinder implementation
• LongPathfinder call forwarding
• Hierarchical Pathfinder definition/implementation

Making the hierarchical pathfinder independent skips this middle and results in cleaner code there.

Finally:

Moving logic from the/a pathfinder to the caller of the pathfinder. If you want to remove the logic of pathfinder1 in pathfinder2, move it to some meta-pathfinder that controls both.

I would say this already exists in CCmpPathfinder.