Some matchers define custom negation logic using `does_not_match?`.  You can see how rspec-expectations uses that internally, falling back to `matches?`:

https://github.com/rspec/rspec-expectations/blob/a74dee7a8a50df0f0d11e62697f1cf3b6ac39a61/lib/rspec/expectations/handler.rb#L48-L51

The reason for this is for a case like this:

``` ruby
expect(some_object).not_to respond_to(:foo, :bar)
```

The `respond_to` matcher has separate negative matching logic for this:

https://github.com/rspec/rspec-expectations/blob/a74dee7a8a50df0f0d11e62697f1cf3b6ac39a61/lib/rspec/matchers/built_in/respond_to.rb

Because the expectation above is stating that both `:foo` and `:bar` are messages that `some_object` does not respond to (at least, that's what people mean when they use it).  If it simply used the negation of `matches?`, then it would pass if `some_object` responded to `:foo` but not `:bar` or vice versa.