A subset of input keys temporarily stop working

Happening again; neither / nor . are working

This is usually a symptom of a broken terminfo description for whatever terminal you happen to use screen from (specifically, the "ti/te" capabilities). A workaround would probably be to place

  termcapinfo <foo> ti@:te@

in your ~/.screenrc; where <foo> is the name your terminal identifies itself as (via the $TERM value it sets). Note that this change will typically also prevent screen from restoring the terminal's previous contents from before it was run.

If it is a broken terminfo description, then you should probably identify for us:
  - what is the terminal emulator program you're using/running screen inside?
  - what does it identify itself as, with $TERM?
  - is it a laptop keyboard, where the "keypad" overlaps the normal keys (in this case, the workaround may be your only option, as there are some keyboards that don't work well with terminals' "application modes").

Are you using PuTTY? PuTTY by default identifies itself as "xterm" or "xterm-color", even though its numpad sequences are not compatible with xterm's. Please be sure that your $TERM setting is consistent with the actual terminal screen is running under.

I was using TERM=screen. Once I removed this, input started acting normally once again. That would be ok/understandable, except that it was happening very occasionally, for only a few minutes at a time. That makes it seem more "buggy".

My terminal app: iTerm (OS X)
It is a laptop keyboard, but none of the affected keys had any non-standard overlays.

The breakage this morning happened while I was trying to hit ctrl-c. The ctrl-c was not obeyed, and I saw the following on the screen every time I pressed it:
^[OM

I'm not sure I understand: is the problem gone now that you've fixed your $TERM? If so, this bug should be closed out.

It's a bad idea to lie to screen and tell it it's running under "screen" when it's not (despite the fact that this piece of poor advice is apparently all over the web).

I'm not at all surprised by "very occasional" behavior for this sort of mixup. That's exactly the sort of thing that tends to happen when screen is misinformed as to who its parent terminal is. Certain features are often only exercised at particular times by particular applications, and that's when the mismatch between escape sequences would be likely to happen.

Yes, unsetting $TERM removed the problem. Sadly, it re-introduced the "Wuff ---- Wuff!!" and broken backspace inanity, which is what initially prompted me to look for the "poor advice" you mention. One would think that *someone* would offer sane defaults; broken backspace is potentially crippling, and Wuff Wuff is at best annoying.

"Wuff --- Wuff" is the vbell message; to disable it, put "vbell off" in your ~/.screenrc.

The broken backspace thing... hit the backspace key a few times while running "cat" within screen for clues to its source. A common cause is a broken terminfo description (usually on xterm-color, I think), that erroneously describes ^? as the DEL key, rather than backspace. If that's the case, then cat will show sequences like "^[[3~"; a "termcapinfo <your-term> bs=^?:kD=^[[3~" in your .screenrc may fix the problem.

On some setups, you may see ^@ for backspace when running cat. In that case, your terminal configuration needs to be adjusted. Find some setting related to "automatically detect backspace character", and set it explicitly to ^?.

Thanks for the comprehensive explanation. What I ended up doing, which seems to have fixed it, is set my terminal app's terminal type to "xterm" (iTerm: Bookmarks -> Manage Profiles -> Terminal Profiles -> Default -> Type -> xterm, then close/re-open all terminal windows).

That aside, this ticket can be closed. As I understand from what you've written, the dropped input was due to me setting TERM=screen.