I've just been having an interesting discussion with that Jeffers bloke regarding the input relay. After thinking it over, I've decided to go for the simplest of systems and giving each of the entities an array of 'states'. The input relay should work by setting these states on the objects, which are then scanned to see if any combinations exist. At its simplest level, the 'move_left', 'move_up' states can be checked and used to move the player. A more complex scenario would involve the checking of multiple states (or a sequence of states) and setting additional states based on this. When set, these states can be set to raise events on an object and hence, cause a scripted function to be called.
This still raises the issue of exactly where these states are checked for 'multi-states' combos. For movement states (left, right, up, down and the increments between) a single movement function can be called which again uses these individual states to change the position appropriately. As motion will be common to most objects it would be possible to have a natively-coded motion handler to take the pressure off the scripting VM. For other, more customised states, the scripted functions can be used as hopefully these calls won't be as common.
So, input maps will be specified with the Xml game specification. It should be fairly easy to hook up a system that detects a certain input event and sets an appropriate game/entity state. The main issue would be to handle the specialist combinations, but for now I believe that this can be ignored until the gameplay is finalised and things are working as they should. It could turn out that such an exotic system is simply not needed and in the timescales we've got, it's a good idea to cut the wheat from the chaff.
One side-effect of the Entity state system is that it automatically gives me access to a scriptable game/level state system (code reuse is good, kids). Using this to set level objectives and win conditions should be easy.