(When it comes to lost socks, I generally find the Z-stocks helps out, but I appreciate that there might be exceptions in a fortress with a ton of the things in normal use.)
IIRC, claimed socks don't go into stockpiles. That, and lost socks aren't the only things that creatures try to get at endlessly (zwei's demon example is an excellent one that I had not thought of).
I would have preferred "more Z-to-zoom" option on the notifications. e.g. for cancelled "give water" jobs, who is it they were trying to help out? Sometimes it's someone who has just entered a slightly thirsty state, as far as I can tell, but sometimes it is indicative of a bad bit of architecture/excavation having isolated one area of the fortress from the rest. Anyway, enough of specific examples.
I'd like this too, but I'm not exactly sure how it's relevant? I already mentioned that hungry dwarves should probably be exempt from the backoff, and "give water" cancellation spam usually has little to do with pathfinding errors (except when you wall someone off with DELICIOUS AMONTILLADO, but arguably the game
should freak out a bit for that).
And, either way, the forthcoming major release probably does not need too many more distractions.
I have no objection to that. I just think it should get implemented; I'm not fussy as to when.
Or we could use an "ignore" designation. It would work the same as the "forbid" designation, but this one would be applied automatically to items that generate job cancellation spam (and can be filtered for in the item list, so you can detect where problems arise). In addition, it could also work on creatures that scare of dwarves, but only applied by the player, valid until they actually injure a dwarf: that would be useful if you have deep pits full of carp in your dining room that don't endanger your dwarves because of the depth.
Automatically doing something like this is problematic in that it can permanently apply a forbidden status to an object that is only briefly unavailable (like if you accidentally flood your farm stockpiles for a year, or have a long siege). Exponential backoff is strong in that, even if you wall off the Old Bar Stockpile for a hundred years, your dwarves still find it again inside of, say, a year or so.
Interesting post.
Ideally we'd need to come up with some workable solutions for the edge cases. But even as a general rule, exponential backoff with some kind of reasonable maximum cap value is something that warrants consideration even in the short term.
Thanks! I was in class thinking about TCP/IP when it came to me. And besides, unpredictable edge cases are what DF is all about!

Imagine if we capped backoff at just 5 steps? Say in the current implementation, some job cancel spammed once every second. Under a capped exponential backoff, job spam during the first 63 seconds would be reduced from 63 entries to 6. Thereafter, that job would only be tried at rate of once every 32 seconds instead of once every second. That'd be a noticeable result, and probably not make the difference between life or death on eat or drink job spamming.
Perhaps the cap could be a configuration item as well, so that players could move it around to their liking, or turn it off.
I was considering the possibility of an init setting, but I didn't want to get too grandiose with the original suggestion. Worse Is Better and all.
Regarding the default timing, it looks right now as if a dwarf can try to do something once a tick, or even more frequently. I have gotten messages like this before:
Urist McStupidface cancels Store owned item: Item inaccessible. x6734So it would need some fine tuning is what I am trying to say.