This file is super thorough, so well done :).

However, I think the thoroughness gets in the way of its purpose as documentation (which is one of the main purposes of these files).  I don't think users want to read so many scenarios.  Also, each scenario adds to the build time of rspec-core, so it's beneficial to have fewer scenarios instead of more.

Here's how I'd recommend we do this:

* Have 3 scenarios:
  * One with no explicit config (monkey patching will be enabled by default) that shows that the monkey patched methods work.  The scenario can define a spec file with multiple examples.  It'll use raw `describe` and can have one example using rspec-expectations' `should` and one using rspec-mocks' `stub` or `should_receive`.
  * One with `disable_monkey_patching!` config that demonstrates that using the monkey patched APIs fails with `NoMethodError`s.
  * One with `disable_monkey_patching!` that does not use any monkey patched APIs.

Actually, you could probably define a `Background` step that defines all the spec files for each of these cases, and then in the individual scenarios it can define an appropriate `spec_helper` that sets the config.

Thinking about this some more...you may also have to put the use of raw `describe` in a separate file from the user of `stub`, `should` and `should_receive`, since when monkey patching is disabled it'll abort on `describe` and not even get around to calling those other methods.  If you define these in separate files, then in the scenarios you can run `rspec path/to/spec` to selectively run whatever files you want to to demonstrate the goal of the scenario.

How does that sound?