Why should they know the difference between these things? Unless they are trying to implement a new terminal, there isn't much of a reason to know this minutiae. The rationale for the differences between them are mainly historical and not really a good design.
Now, I'm all for a "History of Computing" class being required for CS, but that's another story. I also wish that I had time during undergrad for a "History of Biology/Chemistry/science/alchemy" class (I was a biochem major).
They should know what they are because they use them every day. It's like a racecar driver not knowing the difference between an axle and a wheel, he doesn't have to know how to make them or even fix them, but he should damn well know what they're called. Understanding this issue is fundamental to understanding Unix, and is also a superb way of introducing some classical IPC methods. Last I checked most schools still devote a required class or two to the subjects but somehow it fails to work a good deal of the time.
"The rationale for the differences between them are mainly historical and not really a good design."
The separation of shell, a terminal emulator, and a psuedo-terminal is bad design? Really? I would love to see a rationalization for that. EDIT: Or downvotes will work fine as well I suppose.
Your "system as a whole" is the linux TTY... so exactly not the system as a whole. Furthermore, Alan Cox stepping down 2 years ago does not mean the linux tty system is unmaintained. It is in fact.
The reasons ttys and ptys are in kernel space are numerous. As one example, it needs to be there because different line disciplines are necessary and relying on a userspace program to implement them will not do. Ever notice how su/sudo/passwd/etc don't echo your password? Yeah, that sort of important. Furthermore, ttys in modern systems are tied to job control rather deeply. Implementing correct signal sending, sessions with controlling terminals, forground/background processes, etc in userspace? Have fun.
I could write a book on this subject, but this is easier: "Write a fully functional pty in userspace. If you ever manage to get that far, then compare your work with traditional implementations and defend it."
PS: ptys are not "emulating" anything in any meaningful sense of the word.
Userspace can not echo a password too, its not exactly difficult. And do we really need the job control model as is? If you started from scratch would you design it anything like this at all? And signals, it is all the least successful parts of the unix design...
If you are implementing all of your line disciplines in userspace 1) userspace where? 2) How do you handle other modes, besides just noecho? 3) How do you do that while minimizing responsibilities of user generated code?
"And do we really need the job control model as is?"
If someone is discussing the concepts with the wrong vocabulary, then that means they are sufficiently important to that person that the should have known about it.
I wouldn't be noticing that many people don't understand the concepts if it were not relevant to these people. It's not like these are particularly deep subjects either, people directly interact with 2 of the 3 every day. They're not buried details, they're frontline human-computer interfaces.
P.S. Understanding cars is very similar to understanding computers. There are numerous layers of abstraction in place that allow us to rope off areas of understanding for later. I would argue that there is actually more information to learn about cars than there is computers for a few reasons: 1) cars are jam packed full of computers these days. 2) there are half a dozen engineering and science disciplines involved in cars off the top of my head, and that number is only limited by the number I know the name of. 3) (depending on if we're pulling in computing hardware into the discussion or not..) cars are things built in the real world with imperfect knowledge of all the systems that go into them. You can be sure people a century ago were not paying a ton of attention to fluid dynamics in engine cylinders. You can always dig deeper into what is actually going on.
My point is here is that if computers are more complicated than cars, it's not by much. I believe my comparison holds.
Each time you have to answer "why does Ctrl-Left go back a word on my laptop, but when I ssh into my server, it just prints some weird characters?", it's useful to know the distinctions between terminals and shells.
That just sounds like a broken implementation of readline or some such. When I ssh, everything works fine.
Anyway, the distinction is only important in very narrow cases. I've heard people say "Open a new terminal", "Open a new command window", "Open a new shell", and "Open a new console". They mean the same thing in this context. The contexts where they don't and where that fact needs to be spelled out don't come up very often. This unwarranted attention to detail is analogous to changing a flat tire with a friend by saying: "Hey, grab the spare wheel out of the trunk" vs. "Hey, grab the spare tire out of the trunk". This whole thread is like seeing that there are technical differences between a wheel and a tire in the context of a repair shop, but in the context of "get me the circular thing from the trunk that I can attach to my damn car to make it go again" they're the same, and then complaining when people use the second context and don't keep the terms distinct.
It's not a broken implementation of readline, it's either a failure to use readline or improperly set terminfo. TTYs in canonical mode will support backspacing, but not moving around inside text. "Ctrl-Left go back a word on my laptop, but when I ssh into my server, it just prints some weird characters?" reaks of straight up canonical mode.
And say you had this problem, guess what is not going to work? "I have a problem with my command window", "I have a problem with my console", "I have a problem with my TTY".
Now, I'm all for a "History of Computing" class being required for CS, but that's another story. I also wish that I had time during undergrad for a "History of Biology/Chemistry/science/alchemy" class (I was a biochem major).