It occurs to me that what the TTY interface needs is a replanning. Something like:
1: Work up a new interface ('nu-serial') that communicates serial data and related out-of-band information in a sensible, linear way. Don't design this to comply with RS-232, RS-422 or anything - design it to work with data and userspace requirements.
2: Convert userspace programs across to this new interface.
3: Write the TTY driver to connect to the nu-serial interface.
4: Optimise the nu-serial interface to work well with threads and across cores.
5: Phase out the old TTY interface.
The problem seems to me to be that everyone's got a slightly different interpretation of what a TTY should do, and it's being bolted into a whole bunch of things like ppp, KDE and emacs that are needing quite different things from the serial interface. If there's already something like nu-serial, then so much the better.
I'm not a kernel developer, though, so I have no ability to either implement it or guide the project. Some might argue that I shouldn't be saying anything. It does seem to me, however, that this is the approach that's been taken in the past with other things - libata, memory allocators, or schedulers being the first (bad) examples that pop into my head.