It will be best if this can be incorporated in ECP and when received as particular http request passed as message in the event loop in the way isRemoteKeyPressed() is (new isEcpRequest()?) together will additional path and parameters. The only twist remains how to send back data for the http response. It's so simple to implement i would sort of expect it to show in the next SDK release
And one more thing remaining is figuring out what's the current channel on Roku (as to know what queries it can handle if any). That in analogy to "query/apps" and "query/icon" will be something like "query/channel" and simply return ID of the running channel (e.g. "12" for Netflix)
1. In general there is not only one "current" channel running. The most obvious example is a screensaver running over another channel. I think there are also a few other corner cases where more than one brightscript context can be running. So this would need to be clarified; for example, to exclude screensavers.
2. This mechanism doesn't completely solve the race condition you mention in your discussion. The box could return that Pandora is running, and then 100 ms later the user could exit with the physical remote and you'd still be air talking. Perhaps a better solution would be to add a parameter to the input command to specify the id of the channel that you believe you're talking to, and to get a specific error code if the wrong one is running.