+ * The possible ways in which things can go screwy in the front
+ * end are:
+ *
+ * - in a system containing multiple physical buttons button
+ * presses can inadvertently overlap. We can see ABab (caps
+ * meaning button-down and lowercase meaning button-up) when
+ * the user had semantically intended AaBb.
+ *
+ * - in a system where one button is simulated by means of a
+ * modifier key and another button, buttons can mutate
+ * between press and release (possibly during drag). So we
+ * can see Ab instead of Aa.
+ *
+ * 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.