Currently blockrequestifnotloanable only includes holds and bookings for items we own. And digitization requests, if you are using that functionality and not doing the fill locally workflow. We use the fill locally workflow.
A block on resource sharing requesting if people meet criteria of blockrequestifnotloanable block parameters, is essential. We are particularly trying to catch those with fees in excess of a certain amount who won't be able to check out the item they are requesting. With out it we will continue to see two types of behavior. users who cannot check out our items due to a block then getting around it by requesting a scan. Or placing a physical item borrowing request that they cannot check out once it arrives if the fee is not resolved. Thus, we will have incurred effort and in some cases expense for nothing.
If some libraries don't want to block RS under these conditions, it should at least be option to add RS requests to configuration, or you can make it a separate configuration.
We currently as a work around, before the functionality was even available at all, have a manual block created that we get put on automatically via an hourly job. And that gets taken off hourly. Based on criteria. While this is better than nothing -- it has its limitations. It is not immediate in being added or removed. As it is based off a set of users with fees over a certain amount and that repository search only includes actual active fees not transferred fees it doesn't catch a lot of students.
The new blockrequestifnotloanable does include active and transferred fees because we have it set to a parameter to include transferred fees in the active fee bk=lock for fulfillment services. That is why if we could include RS requesting in this block it would cover all our scenarios.