One-person multi-cursor and real-time multiuser cursors carry different semantics

What it is

Several cursors do not necessarily mean several collaborators. One-person multi-cursor may represent batch-edit insertion points, alternatives, or multi-device agents; real-time multiuser cursors primarily express remote attention, position, and impending action. Similar appearance hides different ownership, control, and consequences.

Why it happens

One person's cursors are normally driven together by one command and should be synchronous, predictable, and collectively undoable. Multiuser cursors update independently from sessions and need identity, latency, and concurrency cues. The more fundamental difference between the two is local synchrony versus remote asynchrony: one person's multiple cursors all update locally, within the same event loop, so the position seen at any instant is genuinely the current position. A remote collaborator's cursor position, by contrast, has to travel a network round trip before it can be shown, so "where they're pointing right now" is actually where they were pointing some milliseconds or more ago — a staleness that simply does not exist for local multi-cursors. This is exactly why treating a remote cursor's position as a reliable reference for precise alignment or snapping is risky: it can be stale at any moment, whereas a local batch cursor set, being synchronous, can safely be used for exactly that kind of precise alignment.

Where it stops holding

Both can coexist, such as each collaborator having multiple insertion points, which demands clearer hierarchy. Shared colours, cursor shapes, or undo semantics can conceal critical differences; interaction should not be designed only from a count greater than one.

Applying it

• State cursor ownership, direct controllability, and whether action is batch-local or remote preview.
• Give one-person sets collective selection, range cues, and predictable undo, and feel free to use them as a precise local alignment reference.
• How to check: look for any feature that treats a remote collaborator's cursor position as a real-time precise coordinate (such as snap alignment), and if one exists, test it under artificially induced network latency to see whether stale positions produce incorrect alignment results.

Related

• Same group: C1.24.1 In multi-cursor settings, each cursor needs a visually distinguishable identity marker · C1.24.2 Simultaneous multiuser operation in one area needs arbitration over whose action takes effect · C1.24.4 Increasing cursor count dilutes the state information a single cursor can carry
• Nearby: R1 Collaboration and multi-user interaction · E1 Interface elements and controls
• Search terms: multiple cursors · remote presence · batch editing