Since version 2.1, XFree86 will initialize its keymap from the Linux keymap, as far as possible. However, Linux had 16 entries per key (one for each combination of the Shift, AltGr, Ctrl, Alt modifiers) and presently has 256 entries per key, while X has 4 entries per key (one for each combination of Shift, Mod), so some information is necessarily lost.
First X reads the Xconfig file, where definitions of the LeftAlt, RightAlt, RightCtl, ScrollLock keys as Meta, ModeShift, Compose, ModeLock or ScrollLock might be found - see X386keybd(1), later XFree86kbd(1).
For Mod the LeftAlt key is taken, unless RightCtl was defined as ModeShift or ModeLock, in which case RightCtl is taken, or RightAlt was so defined, in which case RightAlt is taken. This determines how the 4 XFree86 meanings of a key are selected from the 16 Linux meanings. Note that Linux today does not distinguish by default between the two Ctrl keys or between the two Shift keys. X does distinguish.
Now the kernel keymap is read and the usually obvious corresponding X bindings are made. The bindings for the "action keys" Show_Memory, Show_State, Show_Registers, Last_Console, Console_n, Scroll_Backward, Scroll_Forward, Caps_On and Boot are ignored, as are the dead diacriticals, and the locks (except for ShiftLock), and the "ASCII-x" keys.
Next, the definitions in the Xconfig file are used. (Thus, a definition of Compose in Xconfig will override its value as found in the Linux keymap.)
What happens to the strings associated with the function keys? Nothing, X does not have such a concept. (But it is possible to define strings for function keys in xterm - note however that the window manager gets the keys first.)
I don't know how to convince xterm that it should use the X keymap when Alt is pressed; it seems just to look at its resource eightBitInput, and depending on whether that is true or false either set the high order bit of the character, or generate an additional Escape character (just like setmetamode(1) does for the console).