Platforms can be grouped into two broad categories, platforms with "consoles" and platforms with "terminals", according to the paradigms that they present to TUI programs. These are not firm divisions, and several platforms are admixtures of the two approaches.
These platforms provide a concept of a "console" to applications programs. Consoles support direct screen addressing, to the level of character cells at least, and are accessed through an API that is a first-class part of the overall system API. They have two classes of I/O: high-level I/O minly dealing in streams of characters and low-level I/O dealing in queues of events and two-dimensional screen buffer cell arrays.
Microsoft Windows NT, IBM OS/2, TAU, and even (to an extent) MS/PC/DR-DOS are platforms with "consoles".
The console I/O abstraction evolved throughout the 1980s from the original CON device and firmware I/O routines in MS/PC/DR-DOS, through the CON device and VIO/KBD/MOU subsystems in OS/2, to the console I/O mechanisms in Windows NT and TAU.
The Windows NT abstraction even incorporates command history and command aliasing.
Consoles have no notions of keypads with "application" and "normal" modes, no scroll margins, no switchable automatic margins, no pending line wrap, no application-defined tabstops, no canonical/non-canonical input modes, no boldface/faint/italic/strikethrough/underline/invisible/reverse attributes, no database of capabilities to be consulted, no ISO 2022 character set switching, and only the one colour system. There's no session with controlling terminal, nor a setup/teardown dance to perform at job suspend/resume.
These platforms provide a concept of a "terminal" to applications programs. Terminals are not directly addressed, but are communicated with via byte stream communications protocols, involving control characters and control character sequences.
Unices (e.g. the various BSDs, Solaris, HP/UX, AIX, and so forth) and Linux are platforms with "terminals". The terminal I/O abstraction has its roots in the 1960s and 1970s, and some of its concepts can be traced back to Multics. It is formally documented in the Single Unix Specification as the General Terminal Interface.
Terminal I/O has no concept of multiple application-created nonce output buffers. There is no "window rectangle" or "font" known to the I/O paradigm. There's no generalized input event concept. There's no direct manipulation of the output buffer, and no high-level I/O versus low-level I/O. Nor is there an "attached" console and a TUI/GUI dichotomy in program image files. There is definitely no command history/alias mechanism.
Confusingly, platforms with terminals often distinguish one terminal as special, and call it "the console". This isn't the same as the console abstraction discussed here. It's really little more than a way of marking one terminal device out of the many potentially attached to the system that is variously (a) available early on in the bootstrap process, (b) allowed to have superusers logging in directly, or (c) used for kernel diagnostic output and "messages to the system operator sitting at the system console". The console abstraction discussed here is nothing to do with this. The abstractions discussed here involve the API and the way that applications programs "see" the services offered to them by the operating system.