I just had the problem again, and used it to check what has to be restarted in order to resolve it. Note that with careful juggling of right mouse clicks and ALT-TAB (using KDE), even while the problem persists I can address (nearly) every window, or at least kill it, as described in my previous posts.

1. Killing just the X server such that it gets automatically restarted by kdm4 does not resolve the problem. I can log in o.k., but am immediately confronted with mouse events being "stuck" with the first window popping up.

2. Stopping and restarting kdm4 (which also takes down and restarts the X server) -> no resolution, as above.

3. Stopping (in that order) kdm4, hald, dbus, waiting for polkitd, gam_server, and consolekitd to die out, and then restarting dbus, hald, and kdm4 -> no resolution, as above.

4. After 3., one has the process tree shown below:

-+= 00001 root /sbin/init --
 |--= 00171 root adjkerntz -i
 |--= 00801 root /sbin/devd
 |--= 00992 root /usr/sbin/syslogd -s
 |--= 01036 root dhclient: msk0 [priv] (dhclient)
 |--= 01037 root /usr/sbin/rpcbind
 |--= 01157 _dhcp dhclient: msk0 (dhclient)
 |--= 01158 root /usr/sbin/mountd -r
 |-+= 01160 root nfsd: master (nfsd)
 | \--- 01161 root nfsd: server (nfsd)
 |--= 01168 root /usr/sbin/rpc.statd
 |--= 01175 root /usr/sbin/rpc.lockd
 |--= 01248 root /usr/sbin/hcsecd -f /etc/bluetooth/hcsecd.conf
 |--= 01323 daemon /usr/sbin/rwhod -p
 |--= 01349 root /usr/local/sbin/cupsd -C /etc/local/cups/cupsd.conf
 |--= 01370 root /usr/local/sbin/nmbd -D -s /etc/local/smb.conf
 |-+= 01377 root /usr/local/sbin/smbd -D -s /etc/local/smb.conf
 | \--- 01423 root /usr/local/sbin/smbd -D -s /etc/local/smb.conf
 |--= 01518 root /usr/sbin/sshd
 |--= 01526 root sendmail: accepting connections (sendmail)
 |--= 01530 smmsp sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)
 |--= 01537 root /usr/sbin/cron -s
 |--= 01582 root /usr/sbin/inetd -wW -C 60
 |--= 02153 root /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid
 |--= 02161 root /usr/sbin/ypbind
 |--= 02171 root /usr/sbin/amd -p -a /... -l syslog /d/auto amd.auto /srcs amd.srcs /users amd.users /vol amd.vol
 |--= 09653 root /usr/sbin/moused -p /dev/psm0 -t auto
 |--= 09671 root /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid
 |-+= 09771 root login [pam] (login)
 | \-+= 10329 root -zsh (zsh)
 |   \-+= 10389 root pstree
 |     \--- 10390 root ps -axwwo user,pid,ppid,pgid,command
 |--= 01613 root /usr/libexec/getty Pc ttyv2
 |--= 01614 root /usr/libexec/getty Pc ttyv3
 |--= 01615 root /usr/libexec/getty Pc ttyv4
 |--= 01616 root /usr/libexec/getty Pc ttyv5
 |--= 01617 root /usr/libexec/getty Pc ttyv6
 \--= 01618 root /usr/libexec/getty Pc ttyv7

If I now also kill the 2 mouse daemons (moused), and then restart them, dbus, hald, and kdm4 -> no resolution, same as above.

5. Rebooting the system resolves the problem.

To me this looks like some graphics card register has been incorrectly programmed, maybe one related to detecting cursor movements outside a certain area?

I hope this analysis helps some kind soul in resolving the problem.

One final remark: When last time the problem occurred, I had a Suse Linux 11.3 running inside a VirtualBox emulator. When I moved the cursor across the vbox, the KDE session within it would behave perfectly normal. That is to say, while the "real" window system exhibited the "stuck window focus for the mouse", the window system in the VirtualBox session was working just fine.