Checking the Keyboard_info tool (2.0 r15170) with a Keyboard that is supposedly an England layout (j k l ; ' \ | ... huh, the last two characters should've been '#' and '~' according to the keyboard key decals... but it looks like this local browser is interpreting them the same as the server-side one did... so that would be OSX blowing it).

Got the same results with a supposedly Korean keyboard.

Will do some more research to figure out where I'm going wrong and comment again. In the meantime, I suppose I shouldn't be surprised that the keyboard info tool is outputting the following.

Schadenfreude:Helpers Schadenfreude$ ./Keyboard_info
** (process:1829): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
** (process:1829): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
** (process:1829): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2017-02-28 16:48:23.329 Keyboard info[1829:35808] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.
Modifiers:
Server Managed : None
Missing from pointer events : lock, control
Layout: 'us'
Layouts: 'us', 'us'
Variant: ''
Variants:
Repeat: None

Interesting, I changed my preferences to a US keyboard, even showed the little keyboard indicator widget in the menu bar with the US flag, but the tool still showed a British layout...
Googled again and found this better answer: ​win32api.LoadKeyboardLayout; any solutions for OSX? which uses ​NSTextInputContext.
This code actually works and replaces the older version in r16345. (this will be backported)

Since the full list of possible "input sources" identifiers is not specified by Apple, it's quite likely that some will be missing, but at least the most common ones are defined and should be detected. (tested with US, British, French and Thai)