Yep, I wouldn't expect `description_when_negated` to be involved in _any_ of those examples.  To understand where it's used, let's talk about where `description` is used:

* It's used for the one-liner syntax (e.g. `it { should matcher }` or `it { is_expected.to matcher }`) to provide a description for the example when it lacks one.  (Until RSpec 3, this was the only place `description` was used).
* Starting in RSpec 3, it's used in composed matcher expressions in failure messages.  For example, consider `expect(list).to include( a_value_within(0.1).of(10) )` -- in RSpec 3, the failure message will be something like:

```
expected #{list.inspect} to include a value within 0.1 of 10
```

...rather than:

```
expected #{list.list} to include #{inspect output of the passed matcher}
```

So, when you negate a matcher, it produces a new matcher object (a `Negation` instance) and we want that to have a good description so that when you pass it as an argument to another matcher and it fails, the produced failure message reads well.  The problem is that English is not regular enough that `Negation` can implement `description` on its own in such a way to always read well.  Instead, we want to allow matchers to define what their description should be when negated, which is where the idea for `description_when_negated` comes from.  `Negation#description` can delegate to that method on the wrapped matcher when the matcher responds to it.

Does that make sense?