That's why I said some heuristic to placing the ladders (and later sappings), rather than some deliberative process to figure out the ideal place to modify the map. Otherwise, you're right, the game would freeze upon announcing a siege, as it tried to figure out if the four ladders should be daisy-chained in one spot or used in four different points of attack. Not to mention placing siege catapults and ballistae.
Ladders and other map modifications really really should occur alongside demoting the siege from omniscient knowledge of the map inside the fortress, otherwise we'll end up with a new class of the "overlooked diagonal route" design flaw that will crush newbies.
Actually, digging is much easier to solve than ladder placement or even climbing.
Expwnent's even gone so far as to
just plain code it as a plugin into DFHack, and it apparently mostly works just fine. All you really needed to do is declare walls as severely high-weight pathing costs, and throw all of them into the connectivity map. That's even easier than climbing or jumping, which requires a different type of connectivity map (showing scalable surfaces, which notably cannot include fortifications or smoothed stone) to be useful.
The main reason digging isn't in the game already is just that it would be highly controversial and potentially raise balance issues. (Digging is already far too easy for players, and invaders making swiss cheese of your maps isn't going to be popular when there are serious advantages for smoothed natural stone walls and floors over constructions.)
The problem with
limited use items is that you have to use a much more advanced heuristic, while digging and climbing are infinite-use.
And again, what the game really needs is multiple layers of connectivity maps, which would increase RAM footprint, and make connectivity updates take longer (which occur every time you have a lever-operated bridge or door open or fluids moving around, potentially cutting off paths). Alternately, you can make a single connectivity map that contains multiple movement types within it, but depending on how you set that up, it could require many more queries per tile than other movement types would. (Meaning: Pathfinding's FPS lag would be inflated
for every pathfinding creature, which would be a serious blow to FPS.)
Now, yes, there are some ways of reformatting pathfinding, but those are, again, things that Toady has not yet really talked about considering doing. Wholesale reformatting of the pathfinding system to something like jump point search, vector pathfinding, or hierarchical pathfinding may well solve some of these problems, but that's a whole different argument.