Difference between 'timeout' and 'after' not immediately clear
The first few lines of the JavaDoc for both methods do not exactly specify their difference. From `timeout` you have to jump to `after` where at the end of the JavaDoc the difference is explained.

I think this can be improved. The first sentence in `timeout` could be more specific to highlight the difference directly.
src/main/java/org/mockito/Mockito.java
src/main/java/org/mockito/Mockito.java
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index 786b716a51..2f247045a2 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -2820,14 +2820,13 @@ public static VerificationMode only() {
     }
 
     /**
-     * Verification will be triggered after given amount of millis, allowing testing of async code.
+     * Verification will be triggered over and over until the given amount of millis, allowing testing of async code.
      * Useful when interactions with the mock object did not happened yet.
-     * Extensive use of after() method can be a code smell - there are better ways of testing concurrent code.
+     * Extensive use of {@code timeout()} method can be a code smell - there are better ways of testing concurrent code.
      * <p>
      * See also {@link #after(long)} method for testing async code.
      * Differences between {@code timeout()} and {@code after} are explained in Javadoc for {@link #after(long)}.
-     * <p>
-     * Extensive use of {@code timeout()} method can be a code smell - there are better ways of testing concurrent code.
+     *
      * <pre class="code"><code class="java">
      *   //passes when someMethod() is called no later than within 100 ms
      *   //exits immediately when verification is satisfied (e.g. may not wait full 100 ms)
@@ -2856,7 +2855,7 @@ public static VerificationWithTimeout timeout(long millis) {
     /**
      * Verification will be triggered after given amount of millis, allowing testing of async code.
      * Useful when interactions with the mock object did not happened yet.
-     * Extensive use of after() method can be a code smell - there are better ways of testing concurrent code.
+     * Extensive use of {@code after()} method can be a code smell - there are better ways of testing concurrent code.
      * <p>
      * Not yet implemented to work with InOrder verification.
      * <p>
