The correct solution is to only consume from the input buffer as many input events as took place during the logical-update period.
That is, since our logical update is 30 milliseconds, you consume only the next 30 millisecond’s worth of events from the buffered input, leaving later inputs in the buffer for the next logical updates to consume.
thereby keeping input and simulation in sync. clever.
the only thing you don't get is the visual feedback between sim steps, like you normally would without long frame times.
now if there was only a way to fix that....
if that last bit could be fixed, you would have the lowest possible overhead simulation, smoothest possible animation, a simulation that didn't get "ahead" of its input, and visual feedback every sim turn, irregardless of frame time. best of all worlds.
the obvious first thing would be to not let the sim run more that one turn between drawing frames when frame times were long.
but your frame times are already long, and now you're drawing a frame after every sim turn. so the number of sim turns queued up waiting to be processed would probably just keep growing, until the frame times dropped back down and it would eventually catch up.
but this is probably ok. for the following reason:
about the only way to get that screen update every sim turn when the frame time is high, is to SLOW DOWN TIME. you slow down everything (well, the sim, but probably not the input checker) to whatever the speed of the slowest component is (the graphics). sort of slipping into "bullet time" as it were. everything moves slow, except the player, who can still react to the slowly changing scene at his/her normal speeds. as the frame time drops back to normal, the simulation speeds back up.
so it may be possible to have the best of all worlds, if you have the game slowdown towards "bullet time" when frame times get long.
suddenly slowing down would probably be ok. the only other option would be to slow down the simulation gradually, which would allow it to get ahead of the graphics feedback to the player. but suddenly speeding up again might be a problem. one could always cap the rate of speed increase to some playable value.
so if slipping into "bullet time" is an acceptable solution for slowdowns, one can have the best of all worlds. having your cake and eating it too, very WITH my religion! <g>.
this means you wouldn't have to limit the game so much based on how many characters you can draw onscreen at once (unless you're developing for a console and they have a problem with the "bullet time" solution).