- * - if we receive (or fabricate) a button down message
- * without having seen a button up for the previously
- * pressed button, we invent the button up before sending
- * the button down.
+ * Definite requirements are:
+ *
+ * - button _presses_ must never be invented or destroyed. If
+ * the user presses two buttons in succession, the button
+ * presses must be transferred to the backend unchanged. So
+ * if we see AaBb , that's fine; if we see ABab (the button
+ * presses inadvertently overlapped) we must somehow
+ * `correct' it to AaBb.
+ *
+ * - every mouse action must end up looking like a press, zero
+ * or more drags, then a release. This allows back ends to
+ * make the _assumption_ that incoming mouse data will be
+ * sane in this regard, and not worry about the details.
+ *
+ * So my policy will be:
+ *
+ * - treat any button-up as a button-up for the currently
+ * pressed button, or ignore it if there is no currently
+ * pressed button.
+ *
+ * - treat any drag as a drag for the currently pressed
+ * button, or ignore it if there is no currently pressed
+ * button.
+ *
+ * - if we see a button-down while another button is currently
+ * pressed, invent a button-up for the first one and then
+ * pass the button-down through as before.