Well it seems I misunderstood some things when we discussed about support Unicode for EventServer, I was persuaded that EvenServer will be deprecated at one time.
If it's not the case then there's no problems I can just up the trac ticket i made for EventServer so :
http://trac.xbmc.org/ticket/12678 (to refresh with discussion here :
https://github.com/xbmc/xbmc/pull/675) to drop need for Http counterpart.
And for Keymaps, it's by itself an advanced feature, and if you use it there's 100% chance that you use advanced commands, perhaps just simple one like ActivateWindow(shutdownmenu).
This would have been great to have better integration of all those in JSON for addons controls from remotes.
About Widget it's a little more complicated, a widget by itself in android does not exist this is a RemoteView. You create the view and send it to the launcher. Then the app behind should close and use an alarm manager for example to update later. Of course if the app that play songs runs it can update the widget. This wont consume anything since there's already a wakelock to play the music.
To have a thread listening all times you need to keep Wifi full on and have wakelock to get data this is consuming a lot of battery if no need, you can of course stop start the thread non stop but it's cpu consuming to start a thread then register if the widget is wake up only for 1/4sec due to any user interaction and you'll loose most of the notifications
And of course a widget should not show a full keyboard but a widget as you say have the small needed actions, like left right select sended via Event Server no need for threads or heavy tcp just a little udp packet.
But if Xbmc shows a dialog when the user navigate from the widget (or from their infrared Remote) they can start the full app to fill the dialog, but it's then clearly too late to have the notification so this is no use to detect if dialog or not in this case.