Would you agree that the whole TTY subsystem makes very little sense in this day and age? Why not let programs operate in raw mode by default and provide user-level library calls for input line buffering?
If anything things should move the other way, with the kernel providing more readline-style line editing in 'line mode' so that programs need to implement less of it themselves. But this would provoke all sorts of arguments over what line editing the kernel should support and so on, and then someday someone will suggest that the kernel should let you implement your own in-kernel line editing using eBPF (or WASM, if one leans that way), so people could push their preferred choice into the kernel when they log in or start up a shell on a new pty.
(I'm the author of the linked-to entry.)
* https://groups.google.com/forum/#!msg/comp.sources.unix/Vejy...
; ls -l <archives path elided>
-rwxr-xr-x. 1 cks man 65536 Dec 4 1991 ./bin/bin.ultrix-mips/atty
The virtual keyboard might be X11 key events in the case of xterm, or a network stream in the case of sshd, or simply the stdin downstream from another terminal in the case of tmux. That keyboard character stream is fed into the write fd of the master end of the PTY.
The virtual display is implemented by processing data read from the read fd of the master end of the PTY. That might involve drawing to an X11 window in the case of xterm, or sending back data over the network in the case of sshd, or writing to stdout connected to another terminal in the case of tmux.
The important part is this: The job control is still done in the kernel as part of the PTY implementation. That implementation is where for example a Ctrl+c (0x03 byte) is converted to a SIGINT which is then sent to the slave program.