While I enjoyed most of Brian's talk, I wasn't particularly convinced by his dislike of refinements. Essentially, it boiled down to "this feature is hard to implement, it hides complexity, and it isn't well specified". The first and third arguments shouldn't matter to us nearly as much as the middle one. And I fail to see how namespacing monkey patches can do anything but decrease and contain accidental complexity (in the same way that method dispatch and polymorphism are better at limiting complexity than explicit conditionals).
The benefit to refinements is in preventing code conflicts from a shared namespace (like monkeypatching a core class).
The downside is it becomes even _harder_ to figure out what code is being run just by reading it. Right now, you just have superclasses and included modules, potentially gummed up by method_missing. Now, you need to also pay attention to refinements included by code that _calls_ the code you're looking at, which may change the way it behaves.
Unless used with great care, it's going to create a nightmare debugging situation. And with some of the code I've seen, it'll happen.
