Reword modifications for clarity

staging/src/k8s.io/client-go/tools/cache/shared_informer.go

@@ -107,17 +107,15 @@ import (
 // For a given SharedInformer and client, the notifications are
 // delivered sequentially.  For a given SharedInformer, client, and
 // object ID, the notifications are delivered in order.  Because
-// `ObjectMeta.UID` has no role in identifying objects, if an object
-// O1 with ID (e.g. namespace and name) X and `ObjectMeta.UID` U1 in
-// the SharedInformer's local cache is deleted and shortly after
-// another relevant object O2 with ID X and `ObjectMeta.UID` U2 is
-// created a client has no guarantee of seeing O1's deletion and
-// O2's creation as two separate notifications, it might as well
-// receive a single update notification where the old object is O1
-// and the new object is O2. Clients that need to detect such cases
-// might do so by comparing the `ObjectMeta.UID` field of the old
-// and the new object in the code that handles update notifications
-// (i.e. `OnUpdate` method of ResourceEventHandler).
+// `ObjectMeta.UID` has no role in identifying objects, it is possible
+// that when (1) object O1 with ID (e.g. namespace and name) X and
+// `ObjectMeta.UID` U1 in the SharedInformer's local cache is deleted
+// and later (2) another object O2 with ID X and ObjectMeta.UID U2 is
+// created the informer's clients are not notified of (1) and (2) but
+// rather are notified only of an update from O1 to O2. Clients that
+// need to detect such cases might do so by comparing the `ObjectMeta.UID`
+// field of the old and the new object in the code that handles update
+// notifications (i.e. `OnUpdate` method of ResourceEventHandler).
 //
 // A client must process each notification promptly; a SharedInformer
 // is not engineered to deal well with a large backlog of