I don't know all the nitty-gritty details, but basically (as I understand it) Vim uses an API to obtain the pressed keys that cannot distinguish between those different keys. For graphical applications like GVIM, all keys could be distinguished without problems; it's just a matter of switching to a more powerful (and GUI-only) API. For terminals, not all can actually distinguish between those keys (with <BS>
/ <C-H>
the only exception). Many modern once can, though, it it again becomes a matter of switching to a more powerful API.
Some people (foremost Paul LeoNerd Evans) want to fix that (even for console Vim in terminals that support this), and have floated various proposals, cp. http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/bfbcb22f37a8a1f8
But as of today, no patches or volunteers have yet come forward, though many have expressed a desire to have this in a future Vim release.
More details on the problem
Due to the way that the keyboard input is handled internally, it unfortunately isn't generally possible today to distinguish certain keys, even in GVIM. Some key combinations, like Ctrl + non-alphabetic cannot be mapped, and Ctrl + letter vs. Ctrl + Shift + letter cannot be distinguished. (Unless your terminal sends a distinct termcap code for it, which most don't.) In insert or command-line mode, try typing the key combination. If nothing happens / is inserted, you cannot use that key combination. This also applies to <Tab>
/ <C-I>
, <CR>
/ <C-M>
/ <Esc>
/ <C-[>
etc. (Only exception is <BS>
/ <C-H>
.) This is a known pain point, and the subject of various discussions on vim_dev and the #vim IRC channel.