add some clarifications

proposals/1719-olm_unwedging.md

@@ -1,8 +1,13 @@
 # Olm unwedging
 
 Olm sessions sometimes get out of sync, resulting in undecryptable messages.
-This proposal documents a method for devices to create a new session to replace
+This can happen for several reasons.  For example, if a user restores their
-the broken session.
+client state from a backup, the client will be using an old ratchet state
+([riot-web#3822](https://github.com/vector-im/riot-web/issues/3822)).  Or a
+client might expire a one-time key that another client is trying to use
+([riot-web#3309](https://github.com/vector-im/riot-web/issues/3309)).  This
+proposal documents a method for devices to create a new session to replace the
+broken session.
 
 ## Proposal
 
@@ -18,11 +23,11 @@ the number of new sessions it creates per device that it receives a message
 from; the client should not create a new session with another device if it has
 already created one for that given device in the past 1 hour.
 
-Clients may wish to ask the sender of the undecryptable messages to re-send the
+Clients may wish to take steps to mitigate the loss of the undecryptable
-message.  For example, if the undecryptable message was a megolm session, then
+messages.  For example, megolm sessions that were sent using the old session
-the client can send an
+would have been lost, so the client can send
-[`m.room_key_request`](https://matrix.org/docs/spec/client_server/r0.4.0.html#m-room-key-request)
+[`m.room_key_request`](https://matrix.org/docs/spec/client_server/latest.html#m-room-key-request)
-message to request that the sender re-send the key.
+messages to re-request any megolm sessions that it is unable to decrypt.
 
 The spec currently says, "If a client has multiple sessions established with
 another device, it should use the session from which it last received a