Some sites offer patrons a second location to pick up holds. Today there is already a user setting to indicate whether a given patron generally prefers to pick up her held items "behind the desk" as opposed to (presumably) at a public holds shelf. The setting has the internal name circ.holds_behind_desk.
As of today this setting can only be changed by staff in the staff client, even though it affects patrons. Further, the setting alone does not always accurately represent the state of any hold, since the value for the setting may have changed since a hold was placed on the shelf. This may result in staff or patrons searching for the item to the wrong location. By applying the value directly to the hold, we can tell with certainty where each hold resides.
The goal of this feature is to implement a per-hold value for the setting, so that the state of each specific hold is known and to allow patrons to set their own value for the behind-the-desk user setting (if allowed).
For additional technical specifications, see http://yeti.esilibrary.com/dev/pub/techspecs/holds-behind-desk.html
I have at least one issue with this feature in general, before or after the proposed changes:
Whether or not the option is "supported" is a true/false at the org unit level, but when "supported" it is a global to the patron option. In a mixed environment the option is effectively unable to be used, it only ends up having meaning when set globally. At that point if a library doesn't *have* a "behind the desk" or otherwise alternate location then the patron will get confused as to why they have the option to begin with.
Couple that with the fact that patrons may use multiple libraries and have different preferences per library (especially with something like the "drive thru" example in the linked document) and I think exposing the option to the patron would create too much confusion. Making it so that you can specify a different preference per library would alleviate some of this concern, but would be a major change to the way it currently works.
In addition to the above, storing the value on the hold before the hold goes to the hold shelf is likely to create confusion as well. We already have issues with patrons changing their default notification options, or phone numbers, and patrons and/or staff getting confused that all of the patron's holds didn't update automatically. Adding another field to holds that this will be a problem for will create additional confusion in that regard. I personally think that storing the value at shelf_time would alleviate this while keeping the ability to tell patrons where their holds are.
Beyond the issues I mention above I would also like to point out that at the moment you don't have any mention of updating receipt printing code to use the new column instead of loading the patron preference for the routing information on hold slips.