Well I know that if I grab and click hold the separator bar in the Browser window just above the senders button, then count to five, I count 80,000 signals to the semaphore, which is spining that ioProcess loop really really fast... As you mention both processes do this together so nothing really gets stacked up. However this is needless work...
Be that as it may but unless you fix the clients not to use Sensor there is really nothing you can do. Sensor polls and because of the VMs event support we have to make sure we get the appropriate state pulled in from the VMs event buffer. If we don't, then the polling loop will sit there forever.
Besides, signalling the event semaphore from the VM will only work if you have a multi-threaded VM implementation which can process incoming UI events in parallel to the VM's loop. If you don't, then you'll only get new events every 500ms or so (depending on what your VM interrupt check counter says) so not stimulating the input semaphore is not an option given all the non-multithreaded implementations.
I might add that I've been over all of this many, MANY times. While the current version might be inefficient it is the only way to preserve the expected notions from its clients - if you want to reduce the needless work done here then you need to fix the clients to work with our (not so) new assumptions (e.g., being event-driven no client should poll for state and expect it to change in its polling loops). Once you do this, you can rewrite everything in terms of the morphic hand rather than Sensor's polling API (which is the right thing to do).
Cheers, - Andreas