Updated for recent decisions and clasrified some things.

src/ZEO/ordering.rst

@@ -226,8 +226,11 @@ T2
 
 B2
   Here, we avoid incorrect returned values and incorrect cache at the
-  cost of caching nothing. For this reason, a future ZEO 4 revision
-  will require ZODB 4 or earlier.
+  cost of caching nothing.
+
+  ZEO 4.2.0 addressed this by using the same locking strategy for
+  ``loadBefore`` that was used for ``load``, thus mitigating B2 the
+  same way it mitigates T2.
 
 ZEO 5
 -----
@@ -252,16 +255,16 @@ asyncio's ``call_soon_threadsafe`` to send invalidations in a client's
 thread.  This could easily cause invalidations to be sent after loads.
 As shown above, this isn't a problem for ZODB 5, at least assuming
 that invalidations arrive in order.  This would be a problem for
-ZODB 4.
+ZODB 4.  For this reason, we require ZODB 5 for ZEO 5.
 
 Note that this approach can't cause invalidations to be sent early,
 because they could only be sent by the thread that's busy loading, so
 scenario 2 wouldn't happen.
 
-To mitigate T1, we could create a thread-safe server-side message
-queue that's used when sending results.  Unfortunately, this puts us
-back in the position of having to wake up the event loop again (via
-``call_soon_threadsafe``). Maybe that's OK.
+B2
+  Because the server send invalidations by calling
+  ``call_soon_threadsafe``, it's impoossible for invalidations to be
+  send while a load request is being handled.
 
 The main server opportunity is allowing commits for separate oids to
 happen concurrently. This wouldn't effect the invalidation/load