Xterm reads its termcap entry in order to set stty erase to the correct value. The correct value is 'stty erase ^H' since that is what xterm by default produces for a BackSpace keysym, and that is what the termcap/terminfo entries say (kb/kbs). Unfortunately, xterm reads the wrong termcap entry (kD equivalent to terminfo entry kdch1) and sets the tty erase character to ^?. This means programs that don't autocompensate (cat, ftp, anything not linked to readline) get confused and you can't delete with the expected button. And programs that use readline lose the ability to delete to the right (delete the character under the cursor) which is the real meaning of kdch1 as per the terminfo docs (and what any new user would expect). This could otherwise be achieved with a line DEL: delete-char in /etc/inputrc. I linked to a patch that fixes it. According to the xterm FAQ on http://www.clark.net/pub/dickey/xterm/xterm.faq.html this is the way it was originally, don't know who broke it, but they didn't read the kD entry on man 5 termcap first. An additional problem is that the xterm termcap entry would be over 1023 characters, so it is truncated when converting from terminfo. This means that the kD (kdch1) info is missing (doubly ironic when xterm tries wrongly to read it to set the tty), so xterm does not know how to send the data from the Delete key. Xterm sends ^?, while apps that read terminfo will expect ^[[3~ like on the linux console. This is a smaller problem since the line above will fix things for readline apps that make up the majority of apps that would know what to do with the delete key anyway.
I forgot to mention, you have to reverse the 'aaargh' patch to the latest termcap (2.0.8-18) before xterm can see the termcap entry at all. The aaargh patch breaks the API. Probably should be redone so it works the old way unless the TERMCAP entry is overlong. Not sure what it was supposed to fix, anyway.
It's a security fix; it will most likely *not* be reverted.
xterm terminfo stuff fixed for next release.