> An alternative is to maintain a list of compatible formatters and have formatter developers add them to that list when the formatter is required.

:-1:  I'm not a fan of that idea.

Alternate idea: instead of having formatters implement `notifications`, we document that their `initialize` method must accept a `notifications` arg and they must register the list of notifications they support with it.  The purpose of this notifications business is to provide a way for formatters to tell us something, and the normal way ruby objects tell another object something is to send a message (i.e. call a method), so I think the semantics of having them call a method from `initialize` lines up with what we're trying to do, anyway.

The `def notifications` approach is also prone to hidden bugs when users typo it:

``` ruby
class MyCoolFormatter < RSpec::Core::BaseFormatter
  def notifcations
    super + [:some_other_event]
  end

  def some_other_event(notification)
  end
end
```

Here I've typoed `notifcations` and it will simply not get called but that won't be obvious.  In contrast, if I'm required to call `notifications.register(base_notifications + [:some_other_event])`, typos will fail loudly and quickly.  It'll also avoid this kind of weirdness where the user has to define a method that seemingly doesn't need to be there.