I think it is a short somewhere, probably caused by some debris, dust or liquid. I've had something similar happen with ThinkPad keyboards.
Try using a vacuum cleaner, with the nozzle over the keys, and particularly on the edges of the keyboard (as you seem to have removed it anyway). I'd use a clean vacuum cleaner bag, in case you need to recover any keycaps that get sucked up.
If that fails you could try a can of compressed air. Then you can try drying it in a warm (but not hot or humid) area, in case it is liquid shorting it out.
If none of that works you may need to get a replacement keyboard from eBay or similar.
It is possible that a little more detail would help answer this question. As it stands, I would approach this problem by trying to troubleshoot step-by-step, and here are some steps I would consider.
If you have access to a different Apple or other vendor's USB keyboard, attempt to use that to see if the problem recurs. It is possible that your particular keyboard and/or laptop USB ports have a problem.
I would check your terminal emulation type with:
$ printenv TERM
xterm-256color
If it is not "xterm-256color" (the default for new windows in OS X's Terminal) then you may wish to consider setting your window to use that via Terminal's preferences. (This assumes you are using Terminal, and not an alternative, like iTerm.)
If you are using the "screen" utility or an SSH session, you may wish to try the same processes without them. If the problem repeats without them, you've gained some more information. If the problem doesn't repeat, then the configuration for those utilities or the interaction with your shell may be at issue, and you can look further into that.
Your tags indicate that Zsh might be in use. Determine if you have the same problem if you switch to bash (the default for OS X since Mac OS X 10.3 Panther) or another shell. A benefit of trying this that Bash and Zsh shouldn't share any or many configuration files. So, the possibility of a particular customized configuration for either shell being the culprit would be minimized.
If another shell doesn't have the same problem, you will need to determine whether the shell configuration or shell itself is the problem. If the shell you normally use has been customized, I'd back up and eliminate that customization before starting a new session. If the new session works, then it stands to reason there's a problem in your specific shell configuration.
You could also try the above steps with a fresh new OS X user account, which will inherit default settings from the localized user template for your language. This user account can be created and removed after testing via System Preferences > Users & Groups (as it is named in OS X Mountain Lion). This step would generally eliminate any other keyboard layouts that have been installed, as well as software that might modify keyboard behavior. Even if such software was installed for all users on the system, it is probably not set up as a Login Item for new users.
Best Answer
Abstract
As others have indicated, it the Fn key is a special case handled internally. I'll provide the technical explanation.
Technical Details
When you press a key on a keyboard, the keyboard controller (a small IC chip inside the keyboard) detects the electrical circuit and processes it to decode which key was pressed and then sends the scancode to the motherboard. The operating system receives scancode from the BIOS and then performs whatever action it needs to in order to process that keypress.
With most keys, this is simple enough. If you press the A key, its keyboard controller sends the scancode to the motherboard which then passes it to the OS which in turn usually prints 'A'. (If the OS detects that one of the modifier keys is currently held down, then it may do something different. In fact, you can configure it to do whatever you want when the A key is pressed with or without modifiers.)
Now the Fn key is special. When you press it by itself, nothing happens because it is exclusively a modifier key and is not (generally) meant to do anything on its own. When you hold it and press another key, the keyboard controller detects that and looks in its built-in table to see if it is a known combination. If the combo is not in the table, then it just ignores it, but if the combo is in the table, then it looks up the associated scancode and sends that.
What does the OS end up seeing? It does not see the scancode for the Fn key and the scancode for the other key. Instead, it sees a single scancode associated with whatever function the Fn-combo has been set to. For example, if the laptop manufacturer has set the Fn+Down Arrow combo to reduce the volume, then the OS sees the scancode associated with the Volume Down, which some keyboards actually have.
Application
So how does this explain why holding Fn on the laptop and pressing a key on an external keyboard does not work? Simple, because the keyboard in the laptop and the external one each have their own controllers. As far as the controller in the laptop sees, you pressed and released the Fn key and as far as the controller in the external one sees, you pressed and released the other key. What does the OS see? It sees that you only pressed the other key without any modifiers.
Demonstration
You can see that Fn key handling is special with a simple test. Plug two external keyboards into a laptop (thus giving you three keyboards). Hold the Ctrl key on one keyboard, the Shift key on another one, and then press the Escape key on the third. The Windows Task Manager should pop up. Why? Because Windows received the scancodes for all three keys, one from each of the three keyboards' controllers. (This was a Windows example, but pressing key combos in this manner should work the same in other operating systems. For example, even in DOS, you can reboot the system by pressing Ctrl+Alt+Delete on different keyboards.)
Note
Note: the information about how the Fn is specially processed and the resulting limitations on its use are only general, based on common implementations. There is nothing stopping a laptop manufacturer from deciding to implement it differently and allow the user to remap the key to some other function, provide an emulated Fn key on external keyboards via some specific chord, etc. In fact, there is not even an official standard for the Fn key; most manufacturers just use the same implementation that others have used because it's cheaper and changing what users are accustomed to is usually not good.