I found a case where a shift, when it is the second part of a hotkey appears to stick down long enough that it fools an InputBox into thinking it's down for the duration of the box's existence. Interestingly, if I reverse the order of the keys, the shift is no longer a problem. Here's my code.
Code:
AppsKey & RShift::
RShift & AppsKey::
;SendInput, {shiftup}
;Sleep, 200
InputBox, UserInput, Text Entry Box, Enter text., , 490, 119
Return
When I press AppsKey & RShift, whatever I type in the InputBox is in caps as if the shift key is stuck down. But if I use the RShift & AppsKey combination instead, it works correctly. My workaround for the AppsKey & RShift problem is to uncomment either of the two commented lines ({shiftup} or the Sleep) and that solves it. However, I thought this might be something that Chris would class as a bug in AHK and would want to fix it somewhere in the core AHK code.