I would suggest that the Cancel Hold button is overly complicated and should be simplified. At the very least, this should be an option. Currently (3.22.8) it doesn't seem to matter if there is another hold or if the item is a local item or going somewhere. Its behavior doesn't differ from one button to the next. Aside from that, if this function were to be fixed, say, bug 17010, it really doesn't matter (at least to some libraries) what happens next. The behavior following the press of the button should be self evident. One could also assume that getting information as to what happens next to each hold and customizing the button is using processing time to build the page. Time which is a waste. I think that the buttons next to all the holds should just simply read "Cancel hold". If it is an issue, this should be a preference, that would eliminate any background processes building the buttons, and give a simple Cancel hold label.
The check-in page shows a dialog telling the user that a transfer is required when checking in an item from another library. I think adding the same thing to this page would eliminate the need for a "Cancel and return to..." button label.
(In reply to Owen Leonard from comment #1) > The check-in page shows a dialog telling the user that a transfer is > required when checking in an item from another library. I think adding the > same thing to this page would eliminate the need for a "Cancel and return > to..." button label. +1