> They can't be relying on the behaviour, as it's new behaviour, they can only be relying on the old behaviour, which is provided by color_enabled? which is why it recommends it.

Oh good point.  So in that case, I do think you need a deprecation warning for the case I mentioned.  Something like this:

``` ruby
      NoArgument = "No such argument"
      def color(output = NoArgument)
        if output == NoArgument
          rspec_2_value = color_enabled?(output_stream)
          rspec_3_value = value_for(:color, @color)

          if rspec_2_value != rspec_3_value
            RSpec.warn_deprecation(<<-EOS.gsub(/^\s+\|/, ''))
              |The semantics of `RSpec::Core::Configuration#color` are changing in RSpec 3.
              |In RSpec 2.x, it took `output_stream.tty?` into account but in RSpec 3 it
              |only indicates how the user has configured `color`, and `color_enabled?`
              |provides the RSpec 2.x behavior. You've hit upon the rare situation where
              |`color` is enabled by the user but the output stream cannot support it. You
              |need to switch to `color_enabled?` to keep the current behavior, or you can
              |ignore this message and keep using `color` if you don't care about the
              |capabilities of `output_stream`.
            EOS
          end

          rspec_2_value
        else
          RSpec.deprecate 'RSpec::Core::Configuration#color(output)',
                          :replacement => 'RSpec::Core::Configuration#color_enabled?(output)'
          color_enabled? output
        end
      end
```