I assume that you see the same behavior with other X applications, i.e. it's
not xterm-specific?
No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
no matter if the mouse pointer is really inside or on blue window frame or
(for blind keys:) really outside.
Actually, maybe this is an xterm problem?
It seems to be somehow related to the xterm's --enable-toolbar configuration
(which is turned on in the cygwin package). If I rebuild xterm with that
disabled, the problem goes away, and I can also reproduce the problem on F15
under twm if I build xterm with --enable-toolbar there (which is not enabled
in the distro supplied package)
hmm - I'm not clear on precisely what a "blind key" is. Sounds like a
compose sequence - and if so, it's puzzling that passing key-presses from
different levels in the widget hierarchy would interfere with that.
The main difference with the toolbar configuration is that xterm's using a
form to contain the toolbar and the vt100 window. The buttons take care
of themselves, but that area to the right of the buttons is dead.
To make it somewhat friendlier, xterm adds the actions used for the vt100
window (except for the ones related to the mouse) to the toolbar area.
I omitted the mouse-related ones since it seems that they'd interfere with
the menus. I also did the same for the scrollbar widget (since keystrokes
there used to be lost - it would seem that you could reproduce your
problem also by looking at the behaviour around the scrollbar).