First of, this question is impossible to be answered in a general context, so the assumption of a Unix(oide) system will prevail. Second, even in a Unix(oide) environment variations are way to large for an exhaustive answer.
Does this mean that everything must be already set up for the user login on this port? Like a TTY driver already listening on the port, the login process already running, and probably the login prompt string already in the output buffer of the port? (And this must be the case for every port that can accept connections from terminals.) In that way, when a terminal connects, it immediately gets the login prompt string, and any characters it sends to the computer are immediately read by the TTY driver and passed to the login process.
No. Why - and even more, how? To start with, there is no guaranteed notification about a terminal being plugged in (or removed) - unless that terminals (and the host) also operates certain additional signals (DTR/DSR). These signals are optional. This is different if the connection is via a modem, as a modem does (usually) handle these signals plus other to inform the host about calls and so on.
Or is there just mechanism that detects the connection of a terminal to a given port (and detects that it is indeed a terminal and not some other type of device) upon which it starts a TTY process for this port, and a login process, and hooks them up so that the login can occur
First of all, on a serial line, everyhing is a terminal. There are no 'other' devices.
Second, there is no secret detection process. When the terminal services are started, the loginprocess just blurs out to each port a login prompt. No matter if there's a terminal connected or not. If one is connected, the user will see it and may log in. If none is connected, or it was turned off during startup, one has to press
CR to get a reaction. Usually the login promt again. That's the way the login process notices that there is a terminal and someone wants to interact.
Always keep in mind, we are talking a very simple environment here. something that can be operated with a teletype - a mechanical device.
(i.e. the above diagram is incorrect)?
No, it just does not describe that part of the process. It only ilustrates that the Kernel offers access to the terminal interface via a device called TTY1
If my terminal is connected to a given port, and I'm already logged in, then I disconnect my terminal and connect it to another free port, do I have to repeat the login?
A login is tied to a port, not a terminal. The terminal has no way to tell the host that it moved - nor does the host know how to handle this. The host handles a port with an optional terminal connected, not a terminal
What happens with the login on the old port, or what state the new one is in depends on what happened before. Usually you need to login again - and then kill the process on the other port - as you will be still logged on on there.
If my terminal is connected to a given port and I'm logged in, then I physically disconnect my terminal from the port (the port is now free) without logging out, and then some other user connects his terminal to the same port, is he then logged into my account (or is there an automatic logout when a terminal disconnects)?
Again, depends on the hardware support for that interface. If DTR/DSR is supported, a host may decide to end a login. if it isn't, the login will stay present at this port.
If I'm logged in and I power off my terminal without logging out, then the next day turn it on again, am I still logged in, and connected to the same application that I left the day before?
Usually yes (again, depending on signal handling and program).
Do ports used by terminals only work with terminals and not with other types of devices (because they must be set up in a way that the automatic detection of connections and the login process may occur)?
There ist no automatic detection per se. While it would be possible to do so, at least with some high level terminals, I'm not sure if that has ever been implemented.
Thus connecting, for example, a printer to a port that is usually used for terminals wouldn't work (except if the printer would "pretend" to be a terminal and simulate the manual login of a user)?
Again, these are features defined by the application. For the OS a serial port is just a serial port. Everything above exchange of data is already application layer.
Form these questions it seams a bit as if you expect a serial port to be more than it is - and similar imply certain levels of drivers or OS handling. While this may be true for some OS and environments it's not guranteed by any default behaviour.
In a Unix(oide) system there is just a serial port. It can have some process assigned. If that's getty, then its interaction on this line will be asking for a login, and when given hand the the execution over to a shell. This is already an application level. Nothing done by a driver. This means there is also no driver to hand over logins to other ports, or similar.
If at all, the only message the driver may sent to whatever application right now controls the process is a SIGHUP when he identifies a disconnect. If and how this application reacts depends on the application.
On a serial port there is a serial device. What kind of device this is is not defined. It's up to the application to interact accordingly - that's why it may be a good idea to not start a getty on a port with a printer plugged in, but maybe some spool. But that's nothing the OS will check - or even offer a way to check.
Keep in mind, all of this is designed communicate with some mechanical teletype - this is so far from a high level world you may have in mind as an ox-cart is from a semi truck - still, both can be used to transport stuff on the same road :))