Obviously a keymap switcher should integrate well with switching input methods.

This is bit unclear sentence. IMHO, from user POV, deskbar replicant for switching keymaps for "phonetical" alphabets, shoudln't contain choice for input methods.
Maybe only in additional advanced section which allows to set different shorcuts to activate this or that InputMethod. But in this case deskbar idndicator would contain second display field, separate from base keymap field.
Keymap is primary thing in relation to Input Methods. To be more clean - user of input methods need ability to set basic "phonetical" keymap (variation of latin in simplest case) to that which suits his/her "physical" keyboard better. And Input Method - to use just that keymapping.
Only thing I can propose for better integration is keymap locking (by blocking switcher) while input method is activated.

I write in three languages: English, Spanish and Japanese. For the first two, a keymap switcher does the job. The latter uses an input method that is enabled/disabled using a toggle key combination (alt-space in BeOS/Haiku). If my memory does not fail, I think the keymap switch only works when the input method is disabled, and when the input method is enabled, the keymap always returns to whatever system-wide keymap has been chosen as default (which usually is whatever matches your physical keyboard).

As it is now, the keymap switching and the input method toggling are independent one from the other, so they would require separate separate deskbar replicants. I guess they could be combined into one replicant, but I am not sure what that would mean under the hood. FWIW.

As it is now, the keymap switching and the input method toggling are independent one from the other, so they would require separate separate deskbar replicants. I guess they could be combined into one replicant, but I am not sure what that would mean under the hood. FWIW.

With single input method situation is not so complicated, but I imagine situation when users utilize several input methods. E.g. Hebrew and Japanese, besides, to say, english, german and russian keymaps:) (I know users, who really have need for that!).
But from your talk I got understanding that switcher keymap-locking feature with activated input method is already automagically present in BeOS. So we just need to check that it wouldn't be broken in Haiku.

If someone would like to work on that, note that i'm working on a new keymap management system that would ease implementing this enhancement. Just send me a mail or comment here so there's no wasted effort :)