jtc writes:

>tgetent was changed to truncate termcap entries at 1024 characters.

Indeed. I sent a PR about this last-yearish; rlogin from a Linux box
to a NetbSD/pmax box was killing the netbsd rlogind.  IOW, this is not
purely an x86 problem.   Truncating the termcap entry at 1Kbytes
avoids coredumps, but (depending on the order in which capabilities
are listed) can leave one with a strangely dysfunctional termcap
behaviour.

At the time, jt pointed out that the 1Kbyte restriction is indeed in
the NetBSD section 5 manpage for termcap: 

     Vi allows only 256 characters for string capabilities, and the routines
     in termcap(3) do not check for overflow of this buffer.  The total length
     of a single entry (excluding only escaped newlines) may not exceed 1024.

     Not all programs support all entries.

IIRC, termcap@berekely agreed that the longer-than-1kbyte termcap
entry is a bug.  the Linux community don't seem to care about such
issues (or perhaps more accurately, see the non-operability as  a bug
in non-Linux systems);

Perhaps that mindset is a legacy of the MS-DOS world..

I've never understood the claims about terminfo being more powerful.
There are 26 upper- and 26 lower-case alphabetics, and adding
0-9 for the second char gives up to  5904  possilbe  capabilities.

Is the set of capabilities in termcap too small, or is it an issue of
how they're encoded?  If the former, one (e.g., termcap@Berkeley)
could always define new capabilities without changing the termcap
implementation at all.

--Jonathan