I'd say 1) because of history, 2) because it's a good idea.
Usually we call gnome-terminal
or xterm
a terminal emulator. In the times of yore, there were no terminal emulators, since there were no graphical user interfaces. All there was, was proper terminals, devices with a screen and a keyboard that connected via a serial cable to the computer. Shells were useful then, too, and were written to support taking commands from terminals. (Probably from arbitrary file descriptors, but that doesn't matter.)
With something like Linux virtual terminals and GUI's, it was useful to make them emulate the original terminals, so that old pieces of software would just work, or at least would with minimal changes. That doesn't only mean the shell, but also other programs that interface the "terminal". (ls
? vi
? emacs
?)
Also, the separation is a good idea, since it allows one to swap the terminal emulator and the shell independent of each other. I can use Bash on xterm, or zsh on gnome-terminal, or Bash over an SSH connection, or...
If the parts were tied together, this choice would be harder.
Incidentally, I'm not exactly sure about cmd.exe
implementing the terminal emulation part in itself either. I haven't touched a compiler on Windows in some time, but if I recall correctly, it's possible to create a "console application" without involving cmd.exe
. See here and here.
cmd.exe
Wikipedia page,cmd.exe
corresponds to the Unix terminal, and the Win32 console acts like the shell (or the other way around), but I could be wrong there. – Kusalananda Apr 13 '17 at 15:15