Rewrite some parts of this MSC for clarity and address feedback.

proposals/4023-unsigned-thread-id.md

@@ -1,36 +1,37 @@
 # MSC4023: Thread ID for second-order relation
 
-[MSC3981](https://github.com/matrix-org/matrix-spec-proposals/pull/3981) defines
-a way to recursively load relations in a thread context. However this does not
-let clients determine with certainty in what timeline an event coming from a `/sync`
-should end up in.
-
-If the related event is unknown to the client, the only way to partition things
-correctly is to fetch the related event and confirm whether this event belongs to
-a thread or not.
+Events that have a non-thread relation to other events (eg. reactions) are
+considered to be in the thread that their parent event is in.
+[MSC3981](https://github.com/matrix-org/matrix-spec-proposals/pull/3981)
+defines a way to recursively load such relations with the `/relations` API
+but for such events, it is impossible for a client to know what thread the
+event is in when it arrives from `/sync` unless it already has, or fetches,
+the parent event. This means performing another client-server API request to
+fetch the parent event which is inefficient.
 
 This proposal wants to reduce the amount of work required for clients to partition
-events with certainty in a time efficient manner.
+events with certainty.
 
 ## Proposal
 
-All events in a thread and the second-order relation events should add a `thread_id`
-property in their `unsigned` field definition, referencing the thread root – as
-defined in MSC3440.
+Whenever a server returns events in the client-server API, it adds a `thread_id`
+property to the `unsigned` field of the event with the ID of the event's thread root
+as defined in MSC3440. This applies to any endpoint that returns events including
+`/sync` and `/messages`.
 
 ```jsonc
 {
-  "thread_id": "$event_id"
+  "unsigned": {
+    "thread_id": "$event_id"
+  }
 }
 ```
 
 All events that are not part of a thread should fill the `thread_id` property with
 the special value `main` – as defined in MSC3771.
 
 If a server does not have the first-order event, the unsigned `thread_id` property
-should be filled with a `null` value. When the server gets a hold of the first-order
-event, it should retroactively update the `thread_id` property and communicate the
-change to clients.
+should be filled with a `null` value.
 
 ## Potential issues
 
@@ -48,7 +49,9 @@ yet received the event being reacted to).
 ## Alternatives
 
 If "[MSC3051: A scalable relation format](https://github.com/matrix-org/matrix-spec-proposals/pull/3051)"
-was to be adopted, this MSC would be nulled.
+were to be adopted, second-order relations could specify their thread directly as one of the relationships,
+in which case this MSC would become unnecessary. However, that MSC is a longer term evolution of the protocol
+and will take time for the ecosystem to adopt. This MSC is intended as a much shorter term fix.
 
 ## Security considerations