Your code example of a named global scope that you can easily disable with
unscoped(:name_goes_here) is exactly what I had in mind too!
I try to avoid global scopes as well, but there are legitimate use cases for them, and thus legitimate use cases to disable them. The two use cases I have in mind are:
soft deletes with for example the acts_as_paranoid gem. Look at the source code of that gem, and the hacks they do to unscope their global scope to allow you to do
SomeModel.with_deleted is a bit mind-bending but works. Unfortunately their hack work because their scope is very simple with a single component in their where condition. It wouldn’t work if their global scope WHERE query had an OR condition.
Basic multi-tenancy with a global scope (example implementation in this screencast). There are cases, for example in a migration script or background job, where you want to migrate all records and thus unscope them.
Named global scopes are a great idea IMO because unscoping them seems like it would make things easier.
Rewhere as mentioned by @Andrew_White unfortunately blows away every other global scope that used a where, so say if you have 2 or more global scopes in your app (due to gems, multi-tenancy, etc - this is the case for our app) that use a where, then you’re out of luck. EDIT: what I just said is wrong if the global scopes WHEREs are done on two different fields.
The same goes for a global
unscope to a much larger extent.