>>   > We don't need to choose, since we can get a context menu on
>>   > `down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
>
>     (defun mouse-maybe-context-menu (event)
>       "Bring up a context menu for a long click.
>     See `mouse-long-click-time' and `mouse-context-menu-function'."
>       (interactive "@e")
>       (if (let ((track-mouse t)) (sit-for (/ mouse-long-click-time 1000.0)))
>           (push (cons 'context-menu (cdr event)) unread-command-events)))
>
> It's not good enough for `master` (IIRC the sit-for tends to return nil
> immediately in some circumstances), but I didn't pursue this any further
> given the lack of interest at the time.  I can't think of any reason why
> it should be hard to fix.

This is a much needed feature and it would nice to finish it one way or another.
I tried to use timers, and the result works well in all test cases:

1. Modes that already bind down-mouse-3 continue working without problems,
   so e.g. smerge-popup-context-menu works fine.  BTW, while testing it
   by clicking down-mouse-3 in non-selected windows, I found a problem,
   so a fix for this very rare problem is also included in the patch.

   For the same reason 'popup-menu' needs to be called explicitly
   to be able to select the right window, as the patch does,
   for the case when the mouse is dragged and down-mouse-3
   is released in another window.

2. flyspell.el doesn't need to be changed.  ibuffer.el works too.

3. cua-rect.el helped to fix one problem and now is supported too.

The new user option mouse-3-down-context-menu is based on mouse-1-click-follows-link.
Currently mouse-context-menu-map shows just the Edit menu - filling the content
of the context menu with e.g. mouse-context-menu-function is a separate task.