Understanding a problem is the first half of the path to solving it.
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 when you launch the local emulator from the command line, the "current tty" is linked to the command-line user, not to a remote session; also, should we open a new session (local or remote) on a new terminal, we must synchronize the launching and connection of IP emulators on both sides, least one session's garbage output is going to be executed as commands on the other session, 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, with which it will interfere; 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!]