diff --git a/docs/unfinished.md b/docs/unfinished.md
index d8de345..0110d3e 100644
--- a/docs/unfinished.md
+++ b/docs/unfinished.md
@@ -71,7 +71,8 @@ typed into it, and a function key pressed meanwhile goes on the end of what is
 already waiting. Enter is a new line in the message. The message ends when the
 transmitter has been told to drop and the engine says it has: what went out is
 cleared off the pane, what was typed ahead is kept, and nothing goes out again
-until TX is pressed.
+until TX is pressed. A new message clears the pane the same way, for the case
+where two of them run close enough together that the transmitter never drops.
 
 `{RX}` runs when the message it stands in has been handed over, wherever it
 stands in the macro. Every other action macro runs before the text unless it
@@ -304,9 +305,32 @@ ignored. MMTTY reports the
 transmitter down at other times — the buffer hands it one character at a time
 and keeps it nearly empty — and taking that as the end cleared the pane and shut
 the gate two or three characters into a message, leaving the rest of it to go
-out on the next function key. N1MM does not read that report at all: it binds an
-empty handler to `OnPttEvent` and takes the transmit state from MMTTY's window
-message 32772 instead, which the bridge does not forward yet.
+out on the next function key.
+
+That report is not the only thing that starts the pane again, because it does
+not always come. Two macros pressed one after the other keep the transmitter up
+from the first to the last character, so the engine never reports a drop between
+them, and the pane kept both messages. Everything the engine has been given is
+locked — it cannot be taken back — so a run of macros left a pane with nothing
+in it that could be edited. `DigitalEngineSender.StartAsync` now calls
+`TypeAhead.Started` whenever it keys a new transmission, which drops the last
+message off the pane and keeps whatever was typed ahead.
+
+`TypeAhead.Ended` is called while the state lock is held, for the same reason.
+The drop arrives from the engine on a thread of its own, and a macro pressed on
+the last character of a message got as far as handing its own text over in the
+gap between reading the state and clearing the pane: the new text was wiped off
+the pane while the engine transmitted it. The order was found by reading the
+code, not on the air, and the fix has not been tested against a real engine.
+
+Which of the control's two paths carries the transmit state has not been
+settled. The bridge takes it from `OnPttEvent`, and N1MM's `DigitalInterface`
+binds an empty handler there and reads MMTTY's window message 32772 out of
+`OnTranslateMessage` instead. Both are in the same class, so one of them is a
+leftover, and `docs/digital-bridge.md` argues 32772 cannot reach
+`OnTranslateMessage` at all while the control has an event for it. `OnPttEvent`
+does report drops here, so nothing is missing; it is worth measuring only if the
+reports turn out to be coarser than the message.
 
 Keying is the keyer's, not the window's: `{TX}` and the TX button both go
 through `DigitalEngineSender.Transmit`, so the order to key is always the first