Marcel,

> > [*] The exact semantics for what to report on key down/key up  
> > haven't been figured out yet. My current take is to simply use
> > the X11 key definitions
> 
> How about Unicode? 

We are talking about specific keyboard keys here. Key up/down events report
keys the user presses on a particular keyboard. I don't think Unicode has a
representation for the left and the right shift key... and that's why we can
live without key down/up events (right now they're unused) but not without
the character events. The OS does the mapping for us from the key code[s]
into the actual characters (e.g., when you use some of those multi-key
combination characters such as accents on certain keyboards) so we don't
have to know about these mappings at the Squeak level but can still respond
to whatever we find a good idea (I love the "ctrl" key as fire button).
Eventually, this could even be used to map arbitrarily strange keyboards
into Squeak or to define your own keyboards (some people ARE crazy...)

> One more thing, I just checked the Windows VM sources, and I don't  
> see the input-event semaphore actually being used except as a 
> flag -- no signaling.  I currently signal it whenever an event has
arrived.

To no good use. The semaphore is provided for two reasons: 
#1 - indicating to the VM that we want to use the event driven primitive
set.
#2 - For TRULY asynchronous event notification mechanisms. E.g., if you
would run the event processing loop in a different thread than Squeak that
is the semaphore to signal. For now, this signaling actually hurts more than
it helps (the explanation takes a bit of time so I skip it for now) but it's
not too bad if your machine is fast enough.

BTW, if you've been digging in my sources, please notice that there's a call
to ioProcessEvents() in ioGetNextEvent(). That call is IMPORTANT - if you
leave it out you will get an arbitrarily sluggish behavior.

  - Andreas