I wouldn't call it a "junk drawer". I think creating a Mixin-style module in this case is really unclear. Consider this example:

```ruby
module Foo
  def debug(msg)
    puts "[DEBUG] #{msg}"
  end
end
```

```ruby
class OtherClass
  include Foo

  def initialize
    debug
  end

  def debug
    puts "Called OtherClass"
  end
end
```

In this simple example, the debug method from the Mixin is easily overridden in the including class. I think this is a really bad anti-pattern:

1. It makes debugging significantly harder - the stacktraces are far less clear and intuitive. Keeping it a module with class methods will take the stacktrace directly to the line in the Module. This is not always the case when including a module, especially in Ruby 1.9.2.
2. It makes finding things difficult. If I `ack` across the codebase for `some_method`, especially if that's a common method, I'm going to get a large number of false positives. Wrapping things in a utility class prevents this, because you need to explicitly call the parent class to use the method, making it highly searchable.