If you want this hack to work for you, you'll have to get an idea of how it works, so that in case anything breaks, you know where to look for.
The first step toward understanding the problem is to give a name to relevant concepts.
So we'll herein call "local" the machine that initiates the connection, as well as programs and files on that machine; conversely, we'll call "remote" what's on the other side of the connection.
The goal is to connect the input and output of a local IP emulator to the output and input respectively of a remote IP emulator.
Only the communication channels with which IP emulators interact are either direct devices (in the usual case of pppd), or the "current tty". The previous case obviously does not happen with telnet sessions; the latter is tricky, because the "current tty" is also the channel from which the emulators are initially launched at the command prompt, so that we can't "directly" connect I/Os until both emulators are launched or ready to be launched, least we're going to execute one session's garbage output as commands on the other one, which would recursively produce more garbage.
To get the best ease of use, the local IP emulator has to provide IP to kernel networking, hence be pppd. However, pppd is dumb enough to only accept having data through /dev or thru the current tty; it must be a tty, not a pair of pipe (which would be the obvious design). This is fine for the remote pppd if any, as it can use the telnet session's tty; but for the local pppd, it sucks, as it can't launch the telnet session to connect to; hence, there must some kind of wrapper around it.
Telnet behaves almost correctly with a pair of pipe, except that it will still insist on doing ioctl's to the current tty, and will fail if there isn't one; using telnet without a tty also causes race conditions, so that the whole connection will fail on "slow" computers (fwprc 0.1 worked perfectly on a P/MMX 233, one time out of 6 on a 6x86-P200+, and never on a 486dx2/66).
[Note: if I find the sucker (probably a MULTICS guy, though there must have been UNIX people stupid enough to copy the idea) who invented the principle of "tty" devices by which you read and write from a "same" pseudo-file, instead of having clean pairs of pipes, I strangle him!]