TA: Yeah, it's nice that they can solve an arbitrary labyrinth of your own design, and they'll pick the best possible path, generally. There are some exceptions, like mining where they can mine from multiple sides, and don't try them all.
I still think this is solvable by running the A* with the designated to-be-dug tile made a "pathable-to" tile (within the scope of this particular path-searching attempt only, obviously), and the destination, rather than (as I understand it) accepting its status as a barrier when looking to see which cell one (choosing the first of N,S,W,E,NW,NE,SW,SE, in that order?) can ultimately accesible to dig from and then running A* with that as the destination, even if it means circumnavigating the mountain to approach from the north rather than staying in the same place and digging out from the SE.
As an addition to the discussion, the assignment of a more logical sequence (or resequencing/reassignment, on-the-fly) of digging/channelling/ramping jobs is a different issue, so I won't mention it, but it is related to what I think is the clincher in the pure domain of pathing: i.e. not taking account of currently active (e.g. digger being on the way) channelling, other barrier-building activities or floodgate/bridge operation along the path of a routing actor, or responding in a reasonable manner when said change occurs.
The impression of omniscience falls down a bit when a pathing dwarf (or creature of some other kind[1]) who has happily worked out a route from where they are to a previously unknown area located in a part of the map they have never been before, gets almost all the way there and then finds the way blocked by a change in map dynamics that occured almost immediately after it set off, and then heads back almost all the way to the original starting location to take the alternate route that left unblocked (at the risk of having to repeat if that is blocked off, and not immediately retrying the original route if re-opened just as they turn back). I have no problems with the omniscience (it is less processor intensive than working out the background data to an "Artificial Ignorance" pathing algorithm that requires per-actor knowledge to be gained before each can successfully traverse the most efficient path) but at the risk of needing the reloading of connectivity zones perhaps initiate a "recalculate route" event whenever gaps/barriers are opened/closed.
Perhaps stagger the recalculations task for each actor, after a short semi-random delay, after each path-change event that restricts travel. With similar but slightly less recalculation events for potential route openings (shorter routes being missed having less repurcussions than original routes needing to be diverted). This way it does not all occur on the same tick and (like the generation of an incoming caravan or newborn child entity causes a noticable pause in the game, for me, while it calculates all the new data) but buries itself in the background a little and facilitates a more natural reaction than everyone suddenly reversing direction like some kind of dwarven Village Of The Damned reacting to a world change...
(On the other hand, these 'flaws' in the system do allow various Dwarf Computing dynamic setups to work.
[1] Actually, while my dwarfs tend to be stupid about this, I've had invaders start to enter a relatively short tunnel to the Depot, and then activated the drawbrige (tens of tiles away, definitely not yet reached by the hostile force) designed to force them to reassess and take another branch of tunnel once they hit this barrier. But instead of advancing and
then reassessing, they've immediately turned round, headed back outside and wandered around to the alternate external entrance that is (I freely admit) actually the shortest path given their insufficiently progressed, but would not be if they hadn't responded until meeting the new obstruction. I can only assuming that as an aimless rabble with a generic "search out targets" algorithm, that they reassess their path far more often than a dwarf who tends to attempt a single targetted task until it comes up against an obstacle or realises that the item has dissappeared (e.g. been channeled under). Not noting any appreciable hit in speed, I'm wondering how much extra power they are taking on, or whether it's mitigated by being a general search for "closest thing of interest" rather than "shortest path to specific target", and thus hits 'maximum depth' far sooner. Noting that I might be misconceiving some aspect of the scenario.