Well, I go out for a few hours and come back to discover this!

Lots of good ideas. I'll make the following observations;

I don't like the idea of global focus. Whilst in the ideal world every app would be well-behaved, we know that in the real world some apps will have problems, and these could be harder to pinpoint with global focus. I have predictions of posts along the lines of, "App A not working properly, the left button doesn't work", leading to a month long delay until the developer of App A gets to look at it (this is a hobby right?), whereapon it is discovered that the problem is caused by App B whose developer is MIA. It opens the potential for frustration and applications that are mutually exclusive (at least until fixed). And in the meantime we all know who is going to hear the most about it...Mark.
I think that a major requirement for these hijack mods should be that a mis-behaving app cannot affect the operation of any other app. If we see an issue with one app, we know that it is that app that has the problem. Hijack issues should also be easier to find and eliminate.

So that basically leaves us with 'input focus' = 'display focus'.

I like the idea of abstracting the player itself into a generalised hijack application. (I guess that really means abstracting the init process?)
Obviously hijack itself would need to bind the buttons for the player. If it were possible to also abstract the existing hijack menu structure into something compatible, then I'd like to see a long press bring up a root menu, initially; {Player, Hijack}, that then gets further populated by applications, {Player, Hijack, gpsapp, emphatic, empetc}.
Each entry in this menu gets to bind buttons (except knob.L, and IR_MENUBUTTON.L) and gets a display buffer assigned, and only the currently selected item receives button codes. Timing out from this menu always reverts to the player, as does using the top button. If we could 'skip through' this root menu straight to the hijack menu when there aren't any additional apps bound then that's fine. Then those people who never use 3rd party apps wouldn't see any difference between the new scheme and the existing hijack menu scheme.

As you have observed, it is useful for some apps to sit in the background but still receive selected button codes. I wonder if it'd be possible to then add a LISTEN_BUTTON ioctl that allows the application to receive button codes that the player application receives (and only the player). So (eg) emphatic would BIND_BUTTON all the buttons that it needs during foreground use, and additionally LISTEN_BUTTON those it needs during background use. Since we abstracted the player, the player no longer receives codes when eg gpsapp is active. So pressing the right button on gpsapp would not result in emphatic receiving a button_right code either.

It's just occurred to me that the 'Select Mode' button is hardly ever used in the empeg. AFAIK it's only used when in a player submenu (eg search) or when in transient info mode to redisplay the current song title. I wonder if we could use this to switch rapidly between applications?