There are several ways one might design proximity-adjusted policies.  One is the case you identify -- distance from capturing library to pickup library -- for which the cached value is accurate only when the item circ lib is the capturing lib (well, except for system-level adjustment which widens the net of accuracy, but we'll go with the strictest possible config for this thought experiment).  That case is, in practice, overwhelmingly common [though, of course, I encourage all to check their own data on that], but is also not the only case.

However, it's not true that the only valid policy is meant to model the capture<->pickup distance.  First, it is relatively common that the ownership of an item by a particular location is more important than where it happens to be at any given moment when deciding to whom it should be loaned next.  Take the case of peering agreements between two library systems within a broader consortium, or regional agreements to be lenders of first resort.

But, that's not the whole story, of course.  The obvious reason we cache, and make available, the home<->pickup calculated proximity is because that's what we /can/ know up front.  It's a useful value that we can store for later and avoid having to recalculate it over and over.  But that is not the only value that can be generated by the code that Lebbeous posted.  Indeed, the capture<->pickup proximity /can/ be calculated by that code, and the code posted is only one part of the larger work we're doing.  Specifically, we have already worked out exactly how to make use of the calculated capture<->pickup proximity.  The only outstanding potential problem we foresee is the speed of calculating that on the fly at the time of best-hold selection.  It may turn out to be a non-issue and be plenty fast, of course, which is what it looks like today, but if it is expensive in the context of an item that could fill many holds (probably only relevant when fillable holds are on the order of thousands, but testing will tell), then we will document that fact so that users of the feature can make an informed decision between the two (well, many more, but here presented, two) angles from which to view proximity -- political policy, or physical capture time distance.

There are technical solutions, of one manner or another, to that problem as well, if it exists.  Testing of other, future code will show if the medicine is needed, and whether it's better or worse than the disease.  We've tried to foresee as many issues as possible to provide a solid implementation, and the question Thomas raises is one of those questions, but isn't addressable directly by /this/ code and so is left to later code that can address it.

The second part of the project, Custom Best-hold Selection Order, is what will allow the library to choose from many different points of view, with the code posted here supporting several of those.

And you're correct about FulfILLment, Thomas.  It does have the advantage of being able to assume more about the capture location, but that just means it was an easier home for the first generation of this code, not that it can't be improved and refactored for use in Evergreen.

Finally, thanks, Thomas, for taking the time to read the code and think about potential issues and use cases, as we have.