A platform-agnostic "web" format keyboard event coincidentally nicely works with our cross-platform-ness as well; the platform-specific browser code converts into a WebKeyboardEvent and then all platforms can share the same serialization code. Avi is refactoring our event-forwarding code to make this picture more of a reality, since it is particularly critical for the Mac. He's been having trouble landing it, though; r10464 is a good picture of one of his attempts.
The other interesting twist about input is keyboard accelerators. We provide the shortcut Ctrl-B to hide and show the bookmarks bar, but if you're typing into a web app that is simulating a document editor, perhaps the app wants Ctrl-B to toggle bold. In the spirit of our slogan: "content, not chrome", the web app gets precedence.
This means that keyboard accelerators are first forwarded to the web content, which decides whether or not it wants to process the key, and then they are forwarded back to the browser so the browser can do the default handling. These two handoffs are asynchronous (we wouldn't want the browser to block waiting for a potentially-malicious page to decide to hang instead of processing keys), so the browser effectively gets a message out of the blue from the renderer saying "process this key as if the user just typed it". This is a security hole, though it's predicated on arbitrary code execution in the renderer.
The message, of coUrse, isn't really out of the blue; we know which keys we had previously forwarded to the renderer. So r10563 keeps a queue of keyboard events we'd previously sent to the renderer, and then only trusts our browser-side list of which keystrokes actually happened when it hears back from the renderer that a key was unprocessed.