This isn't specifically a problem with monkeypatching. Not knowing what is in scope right now is a generalized problem with object oriented programming. Scoped monkeypatches doesn't really add to the problem, IMHO.
(Please note I don't even mean that as a criticism of OO per se. Like everything else, it has costs and benefits, and that is, well, actually a bit of both. Things being hidden from you is annoying, but if you switch to something like Haskell you'll find that everything being shown isn't always entirely cool either.)
The badness of monkeypatching is its ability to make non-local changes that stomp on other code. Monkeypatches aren't bad in a general sense. Take away the stomping behavior and you've taken away the badness.
(They might still be "dangerous" but you've moved them out of the "suicidal" territory I believe non-scoped monkeypatches live in.)
Incidentally, Perl has been able to do this for a long time. I've gotten a lot of mileage out of:
local *{'Some::Module::method'} = sub { ... };
my $thing = new Some::Module();
...
$thing->method(...);
...
It's great for testing, great for modifying the way libraries work locally without globally modifying them (in my case, hacking a bit on code shared by many projects in such a way that I can't really add this thing I really need), and so on. A great addition to Ruby that goes a long way towards mitigating some of my fundamental complaints about the language.
In many other languages it is agonizing to see a solution that does 95% of what you want. Without that last 5% it is unusable for your purposes and you are forced to reinvent a wheel.
As dangerous as they are, there is a reason people monkey patch. Refinements will just help remove the downsides.
It's good because you gain an ability to scope your monkey patches.
It's bad because it incentivizes monkey-patches.