1) Use the Robot library built into Java (java.awt.Robot) to send OS-level keystrokes and mouse events
2) Add a method to toggle the use of the Robot library. For example:
se.useNativeKeyboardAndMouse("true") /// default is "false"... or boolean (1 or 0), perhaps?
3) Modify the "typeKeys" method to use Robot when useNativeKeyboardAndMouse is set to true. For example,
se.typeKeys("", "The string to enter")

Note: If the locator argument is an empty string (""), then it is assumed it will just "blindly" type the keyboard events. The keys will be sent (though only incidentally) to the window that has the focus. In the future, if Selenium ever gains native OS widget recognition, perhaps we could properly do something like this:

How about:
se.setNativeInput("true") // or "false"
se.getNativeInput() // returns "true" or "false"

and for typeKeys, how about:
se.typeKeys("window","{ENTER}")

The "window" locator is already a valid dom expression, so that's nice... Also, I'd like to reuse Microsoft's "SendKeys" API for the syntax of sending keys. Read here for more info: http://msdn2.microsoft.com/en-us/library/8c6yea83.aspx

Instead, I implemented separate keyDownNative, keyUpNative and keyPressNative commands that do not accept element locators, and require you to pass in integer java.awt.event.KeyEvent keycodes. http://java.sun.com/javase/6/docs/api/java/awt/event/KeyEvent.html

These commands do not support the regular shiftKeyDown, altKeyDown, metaKeyDown and controlKeyDown commands; instead you have to separately send a keyDownNative(KeyEvent.VK_SHIFT) to hold down shift in a "native" way. You also have to manually focus on the element first using the "focus" command.

Finally, I did not implement typeKeysNative; I filed that separately as SRC-377, because it's a lot harder than it looks to convert a given string into native key events.

Is this the correct behavior and only the test case has to be adapted?