Update docs to reflect changed method dispatch behaviour

README.md

@@ -284,7 +284,7 @@ Maybe, but probably not. Partial mocking changes the state of objects in the `Ob
 
 Stubs and expectations are basically the same thing. A stub is just an expectation of zero or more invocations. The `Expectation#stubs` method is syntactic sugar to make the intent of the test more explicit.
 
-When a method is invoked on a mock object, the mock object searches through its expectations from newest to oldest to find one that matches the invocation. After the invocation, the matching expectation might stop matching further invocations.
+When a method is invoked on a mock object, the Mockery searches through its expectations from oldest to newest to find one that matches the invocation. After the invocation, the matching expectation might stop matching further invocations.
 
 See the [documentation](https://mocha.jamesmead.org/Mocha/Mock.html) for `Mocha::Mock` for further details.
 

lib/mocha/mock.rb

@@ -27,34 +27,27 @@ module Mocha
   # expectation of zero or more invocations. The {#stubs} method is syntactic
   # sugar to make the intent of the test more explicit.
   #
-  # When a method is invoked on a mock object, the mock object searches through
-  # its expectations from newest to oldest to find one that matches the
+  # When a method is invoked on a mock object, the Mockery searches through
+  # its expectations from oldest to newest to find one that matches the
   # invocation. After the invocation, the matching expectation might stop
   # matching further invocations. For example, an +expects(:foo).once+
   # expectation only matches once and will be ignored on future invocations
   # while an +expects(:foo).at_least_once+ expectation will always be matched
   # against invocations.
   #
-  # This scheme allows you to:
-  #
-  # - Set up default stubs in your the +setup+ method of your test class and
-  #   override some of those stubs in individual tests.
-  # - Set up different +once+ expectations for the same method with different
-  #   action per invocation. However, it's better to use the
+  # This scheme allows you to set up different expectations for the same method
+  # with different action per invocation. However, it's better to use the
   #   {Expectation#returns} method with multiple arguments to do this, as
   #   described below.
   #
   # However, there are some possible "gotchas" caused by this scheme:
   #
-  # - if you create an expectation and then a stub for the same method, the
+  # - if you create a stub and then an expectation for the same method, the
   #   stub will always override the expectation and the expectation will never
   #   be met.
-  # - if you create a stub and then an expectation for the same method, the
+  # - if you create an expectation and then a stub for the same method, the
   #   expectation will match, and when it stops matching the stub will be used
   #   instead, possibly masking test failures.
-  # - if you create different expectations for the same method, they will be
-  #   invoked in the opposite order than that in which they were specified,
-  #   rather than the same order.
   #
   # The best thing to do is not set up multiple expectations and stubs for the
   # same method with exactly the same matchers. Instead, use the