The most commonly employed terminal nowadays is a virtual (as opposed to real) terminal. Virtual terminals do not have many of the complexities of real terminals, and dealing with them can make some assumptions as to core always-available functionality, a fair amount of which traes back to Multiscreen on SCO Unix.
Using the tools in the toolset one can set up services that handle TUI login on virtual terminals, and that provide virtual terminals entirely within application mode code, supplementing or even replacing the virtual terminals provided by a Linux or BSD operating system kernel.
To log on over virtual terminals, either kernel or user-space, one sets up ttylogin services.
To use kernel virtual terminals one arranges for such ttylogin services to be enabled and (demand-)started.
Setting up user-space virtual terminals involves similar ttylogin services, additional console-terminal-emulator services, and further services for various realizers, multiplexors, and input methods.
These are configured in various ways.
User-space virtual terminals need various resources, some of which are supplied with the toolset.
Real terminals are comparatively rare nowadays. They attach via serial or parallel ports, and their handling has to include many complexities such as line speeds, modems, hardware flow control, carrier detect, terminal types at the other end of the line, and the fact that one cannot necessarily always assume even a 1980s level of terminal capability.
Using the tools in the toolset one can set up services that handle TUI login on real terminals.
To log on locally from real terminals one sets up ttylogin services that are aliases for a choice of underlying real terminal login services that handle all of the many things that apply to real terminals but not to virtual terminals.
To perform remote log-on as if the system were a real terminal attached to some other system, one sets up console-terminal-emulator services.
On Linux-based operating systems and the BSDs, the console device (/dev/console) is always an alias for a terminal device, but that device can be either a virtual terminal or a real terminal.
(See freebsd-console and linux-console.)
There are only two service bundles supplied as standard that directly provide TUI login on /dev/console itself:
emergency-login@console service
This is intended to provide console login in emergency situations where full normal multiple TUI login is inoperable, and even the system account database may be inoperable or corrupt.
It uses emergency-login.
rescue standard target
This is intended to provide console login in rescue situations where full normal multiple TUI login is inoperable, and uses the system login program.
Neither of these make any effort to avoid concurrent TUI login on the underlying virtual terminal or real terminal.
It is presumed that in both "emergency" and "rescue" modes the full normal multiple TUI login services simply have not been started by system-control (q.v.).
Otherwise, in normal — non-emergency non-rescue mode — operation login on /dev/console is provided by a TUI login service running against the underlying virtual terminal or real terminal, and the /dev/console device is ignored as a terminal.
Historically, SCO Unix in normal full multiple TUI login mode ran login services on both /dev/console and its virtual terminals, the former directly from the otherwise (even then) obsolete "inittab" and the latter from the Service Access Facility that obsoleted it.
It resolved the conflict by wrapping the /dev/console login program inside a vtgetty wrapper that offered the choice of either waiting for all TUI login services on virtual terminals to end, or of forcibly stopping them, before proceeding with console login.
This does not allow for the possibility of the console not being a virtual terminal, and is not a fully functional approach for Linux and the BSDs.