With one type of pathing (a 'trivial' path, never dealing with 'consumable' path-aids) then if the pathing algorithm ever lands on a pathable square that
has already been pathed to[1] then it can usually switch to the new source path if that was quicker[2].
But when bridges may or may not be made, I've already mused that you'd need to end up with a duplication of the possible pathing tree of some kind. A 'simple' method would be to keep the "zero bridging used" map much the same as your current standard one, with a subset of that map duplicated (on a per-node basis, thus not necessarily duplicating in a huge dumb array) for every relevent position that has a zero-bridging distance[3] and a non-zero bridging access with a lower path cost than
all less-bridge routes to get there.
Initially, this would need some propagation of the new duplication of node details along existing paths (though it would essentially be making use of 'cached' pathing formthe previously explored routes along the path-tendrils already explored, so would be far less 'blind' in its search than the original exploration) but once it reached the pathing 'coal face', the usual ongoing feeling around for paths could continue with not just "it cost <foo> to get here, therefore try <foo+1> on any neighbours" but "it cost <foo> to get here with no bridgings used, <bar> to get here with one bridging used, <baz> to get here with two bridgings used [etc], so try <foo+1>, <bar+1>, <baz+1> [etc] on any neighbours".
And when a search tendril includes the possibility to bridge and the upper magnitude measurement (e.g. <baz>) has already used up the possible quota of bridgings, then the <baz+1> is quietly dropped and not propagated across the ignored in the bridged gap.
It
does get complicated when a route from one direction featuring a certain number of bridgings meets and travels anti-parallel to a route from another with a different number (with one having the advantage on travel weight, the othr on bridge numbers), and maybe there could be a cut-off
other than node-linking strictly per bridges behind them, but the aim is that a path discovery can reach almost to the target area with possibility of both low-cost paths having used up all bridgings (and then ends up rejected if it needs a bridge to take the final step) and at least one higher-cost path having spare bridgings that might end up being the only way to cross.
But I can see alternatives, such as noting each and every bridgable-from nodes in the tree, and when a either a successful path is found or everything ends up dead-ending (with, if available, each of these last-ditch bridgings from that spot also noted) the bridgable-from nodes are reactivated in bridging mode in priority of closeness to destination to search out succesful paths, terminating when those feelers encounter weighted path costs on potential neighbours less than the new weighted path cost it would have imposed to get there via the >= number of bridges on this new mode. If there's an easy route without any bridging, it should quickly discard all bridgings. If a short-cut with a single bridge is discovered, it should let that take over as the ideal and then fall back on a search for any two-bridge method (if more than one can be made) that further improves (with note made of potential three-bridge jump offs, if applicable). And so on while additional bridges are possible. Instead of a whole heap of "original node map array" + multiple*"N bridges used map node lists" you 'only' have the original node map and one simple list of nodes that you would want to try bridging off (in the following "bridge++" round... if applicable).
Although admittedly what you save on storage, though, you almost certainly lose on time if a quick three-bridge leapfrog ends up being the only solution to a problem, and effectively the entire map had been searched for a zero-bridge one, then a one-bridge one then a two-bridge one... Which goes a bit against the search for optimisation. (But then again, you could think up scenarios where all the alternatives are less optimal than all others, too.
(BTW, I am of course using "bridging" as a shortcut term for any 'consumable' movement, including ladders and trap-fouling with herded animals. But that does not including 'mining-movement', which would probably be represented by a high-weighting of search paths through the rock, soil or dismantlable barriers, unless the diggers have a finite digging strength/capability of some kind. e.g. sapper-goblins that exhaust themselves and die (or lie their exhausted), or using stone digging tools that wear out.)
[1] I'm trying to backtrack in my mind how A* deals with the specific example of path A having been pursued heavily due to it aiming advantageously 'closer' to the destination, despite heavy weightings against, and path B being an out-and-back-by-another-route path that is low cost but initially a low-prority in the nominally width-wise search tree, but ends up connecting to A (or, more likely, a not yet fully explored branch of A) with a low weight.
[2] And propogating the lower cost (with appropriate increments) back down the found path.
[3] If a square is so far only reached via a single route with one or more bridging options being exercised then it could be reduced to a magnitude-indicating flag, but as soon as multiple routes with competing "low cost but more bridges v.s. high cost but fewer bridges" routes tag that node, you need to consider a form of duplication.