No, my previous comment isn't right.  keyboard.current can not be both the default keyboard for the current language and the user's current keyboard preference.  e.me probably wants to use it for the currently displayed keyboard, and that's what I'm proposing that you do above.

But we also need a way for the keyboard app to know what the default keyboard for the current language is, because I think that keyboard should always be available even if it is not in an currently enabled keyboard layout group.  Maybe that means that keyboard.js has to read shared/resources/keyboard_layouts.json.  (I think that's what the original version of your patch did... )
I don't like having to do XHR on startup, however.  I wonder why this data is read with XHR instead of just being an ordinary file of JS code. If we could include the layout data just like we do keyboard/layout.js I'd be perfectly fine with that solution.