Is that all of the issue?
If we're talking about emacs, rather than the linux kernel, the issue
becomes one of priorities. There are not anywhere near as many people
working on emacs as are working on the linux kernel.
Also, since emacs runs on a large number of platforms (far more than
the linux kernel), portability becomes an issue.
I think that if someone wrote and debugged a "pty helpeer" routine for
emacs which did the right thing for ptys on most or all of the
platforms that emacs uses ptys on, it would be used. Even better
would be if the emacs-lisp support were done as well. It's plausible
that a linux-only solution would be considered useful. [I'm guessing
here, but I'd be suprised if I'm too far off the mark.]
A related question is: is all this effort worth it? [Are pty's even
secure in the general case?] On some systems, the only way to keep
ptys secure is to have them owned by root, with 700 permissions, until
they're allocated to a specific process. Should emacs try and impose
this kind of logic on such systems when it might break other software?
Finally, there's the issue of the ITS model. But, the ITS model isn't
anything like 777 root owned ptys. The ITS model would be better
served by an ioctl that could be run on an allocated pty such that
further opens to the pty would guarantee that data read on an fd from
one open would also be read from an fd from another open. This is
different from the current tty model, but would be very useful for
collaborative work. [It's not reasonable to expect that emacs shell
mode would do the right thing for this case without some additional
design work -- emacs shell mode uses ptys set for half-duplex.
Reasonable collaboration needs something more like full-duplex.]
-- Raul