I think it should look like:

KEY_DOWN  code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_DOWN  code=220, char=' ' (   0), modifiers=00000000, [ALTGR]
KEY_DOWN  code=065, char=' ' (   0), modifiers=00000000, [KEY65]
KEY_UP    code=065, char=' ' (   0), modifiers=00000000, [KEY65]
KEY_UP    code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_UP    code=220, char=' ' (   0), modifiers=00000000, [ALTGR]
KEY_DOWN  code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_CHAR  code=005, char='é' ( 233), modifiers=00000000, [E]
KEY_UP    code=005, char=' ' (   0), modifiers=00000000, [E]

Looks good to me - haven't tested the patch, though. I don't know why AltGr sends an LCTRL event, but maybe it's Windows that does that.

I have this code now for inserting a char in ustr. Anything wrong with this?
I noted that if I hold altgr and keep pressing a letter, cursor only moves half the time, why?
The font doesn't support the character that comes out so I just get boxes for this. Recommend a font that has all these symbols?

I do convert to c string before drawing, perhaps this is why things get screwed up?

int pos = al_ustr_offset(text, cursor);
if(al_ustr_insert_chr(text, pos, event.keyboard.unichar)>0)
{
   ++cursor;
   Push_event(Event(this, "changed"));
}

I've made a patch that skips sending KEY_CHAR events for dead keys. It also sends two char events when that's appropriate. The output of ex_keyboard_events now matches Matthew's 'é' example. Here are some other examples:

'¨', 'o' to get 'ö':

KEY_DOWN  code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_UP    code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_DOWN  code=015, char=' ' (   0), modifiers=00000000, [O]
KEY_CHAR  code=015, char='ö' ( 246), modifiers=00000000, [O]
KEY_UP    code=015, char=' ' (   0), modifiers=00000000, [O]

'¨', 'k', which is an invalid combination, and produces two characters:

KEY_DOWN  code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_UP    code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_DOWN  code=011, char=' ' (   0), modifiers=00000000, [K]
KEY_CHAR  code=011, char='¨' ( 168), modifiers=00000000, [K]
KEY_CHAR  code=011, char='k' ( 107), modifiers=00000000, [K]
KEY_UP    code=011, char=' ' (   0), modifiers=00000000, [K]

'¨', space, to get just the accent:

KEY_DOWN  code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_UP    code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_DOWN  code=075, char=' ' (   0), modifiers=00000000, [SPACE]
KEY_CHAR  code=075, char='¨' ( 168), modifiers=00000000, [SPACE]
KEY_UP    code=075, char=' ' (   0), modifiers=00000000, [SPACE]

Maybe sending two char events for invalid combinations is a bit over the top, but that's how Windows does it.

I don't know why Allegro doesn't use the WM_CHAR messages, but that might be a better fix than checking the return value of ToUnicode to detect dead keys, like I did.

I'm not entirely clear on what the problem is. It seems to have something to do with dead keys, which doesn't quite seem to work the same way on OS X.
I can do "option-e" and the system will wait for me to type another character (say e or k) at which point I will either get é or ´k. In ex_keyboard_events I get CHAR events for "ALT" (with an invalid character code, more on that next) and for "e" and "k", but I don't get character events for é (rather than e) or ´.

I also get "ex_keyboard_events[11907:903] *** -[NSCFString characterAtIndex:]: Range or index out of bounds", which is due to Allegro's keyboard driver asking for the character corresponding to the "ALT" up/down events.

Now, some or all of this is probably due to the way Allegro interprets OS X keyboard events. I can look into it, but I can't give a reliable estimate for when I can do that; it depends on how smoothly some other things I have to do go.

Makes sense.

Yes, I'm sure it is. Actually, there are two calls to characterAtIndex at that point in the code, and two lines of output complaining about it.