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. 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. [Note: if I find the sucker 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!]