The master device looks like a terminal device file, complete with a line discipline that is accessible via
tcsetattr()/&c. and a success result from
isatty(). In fact it is the same line discipline instance as the slave device, and this is how the program on the master side transmits things such as window size changes to the programs on the slave side. It is also how the master-side program signals (an emulated) modem hangup, by setting the line speed to zero and thereby triggering the line discipline's hangup mechanism. (What the text says about line speed is thus incorrect. There is a case where line speed is meaningful.)
The difference lies in read/write I/O. What is read is the sequence of characters that would, for a real terminal, be sent over an actual underlying serial device. What is written is the sequence of characters that, for a real terminal, be received by that actual underlying serial device. In other words: it is the other side of canonical/non-canonical input and output processing by the line discipline.
There are complexities to this, namely packet mode and remote mode. The latter has fallen into desuetude long since, and did not exist in most operating systems even at the start of this century, necessitating patches to Daniel J. Bernstein's old pty tools. The former is not really particularly useful for most tasks, and thus I am not going to cover it in detail in this answer.
The master device is generally not the controlling terminal for the sessions in which master-side processes run. This would be conceptually putting things that are analogues to the internals of a real terminal in the wrong place. The controlling terminal for such sessions is, if it is there at all, another terminal.
This will be the case for programs such as
:terminal, emacs, and
ptybandage (if not part of a pipeline), which are directly rendering to another terminal device and run within an interactive session controlled by that terminal device.
It isn't the case for an SSH server, GUI terminal emulators,
console-terminal-emulator from the nosh toolset,
ptyrun (in normal usage), or monolithic framebuffer terminal emulators such as zhcon. Those are rendering to all sorts of different I/O devices, from buffers and FIFOs in the filesystem in the case of
console-terminal-emulator through TCP sockets to framebuffer and HID class devices, none of which are terminals. Moreover,
console-terminal-emulator, SSH servers, and framebuffer terminal emulators are generally invoked in dæmon contexts where of course there is no controlling terminal for the session to begin with.
Note that the diagram is not definitive. It is not necessarily the case that the master-side process forks the slave-side processes. In nosh-toolset user-space virtual terminals, for example, the slave-side processes are ordinary
ttylogin@* services, forked by the service manager, and there is no direct process relationship between the emulator process on the master side and the login session processes on the slave side. But that is going beyond the scope of this answer.