Clarify example of timeline expansion

proposals/4186-simplified-sliding-sync.md

@@ -195,13 +195,13 @@ If the server does send down extra events, it MUST set the `expanded_timeline` t
 the room.
 
 This behaviour is useful to reduce bandwidth in various cases. For example, a client may specify a list with range
-`[0,99]` and a `timeline_limit` of 10, plus a list with range `[100, <MAX>]` and `timeline_limit` of `1`. This would cause the
-server to return the most recent 10 events for rooms with recent activity, but only 1 event for older rooms (that the
-user is unlikely to visit). If an older room that we previously only returned with one timeline event receives a new
-event, we'll end up sending it down with not just the new event but the previous 10 events as well (despite having sent
-the second to last event previously). If the room then drops below the threshold (and so has timeline limit of 1), and
-then receives another update, the server MAY remember that it has already sent the previous 10 events and only return
-the latest one.
+`[0,99]` and a `timeline_limit` of 10, plus a list with range `[100, <MAX>]` and `timeline_limit` of `1`. This would
+cause the server to return the most recent 10 events for rooms with recent activity, but only 1 event for older rooms
+(that the user is unlikely to visit). If an older room that we previously only returned with one timeline event receives
+a new event, we'll end up sending it down with not just the new event but the previous 10 events as well (despite having
+sent the second to last event previously). If the room then drops below the threshold (and so has `timeline_limit` of
+1), and then receives another update (and so the `timeline_limit` increases back to 10), the server MAY choose to
+remember that it has already sent the previous 10 events and only return the latest event.
 
 #### Required state