It is very confusing, but you don't need to worry about it. First off, think of a UART which itself is a generic term, but think of one that produces a protocol with a start bit, one or two stop bits, 7 or 8 usually data bits, and sometimes parity which is even or odd; it can vary from there which makes it that much worse.
The UART is at TTL levels, whatever that means. It used to be 5 V and now 3.3 V, 1.8 V or whatever; perhaps TTL is the wrong term. THEN you had/have RS-232, RS-422, etc. These are VOLTAGE AND PIN standards, not protocol standards. It is incorrect to mix the terms and say RS-232 when you mean some sort of UART.
Back in the day your UART was on your motherboards and you desired some sort of connector to the outside world with voltage levels that at the time made sense and some sort of standard pinout/cable. So a popular 25 and 9 pin standard was often found for various peripherals, and in the Wintel PC world this was called a COMmunication port or sometimes serial port.
Sure, a port that carries serial data can and is called a serial port, SPI, I²C, MDIO, UART, HDLC, SDLC, etc., and perhaps even USB and SCSI; you could go crazy with this. Usually a serial port means some pins you can get at a UART.
The Unix/Linux world says
tty instead of
uart, but it is the same thing.
Now there is the IMPLEMENTATION. You can buy some UART chip with some interface on it (yep, you can have a SPI UART, which is serial on both ends, or I²C UART or some dedicated bus or USB, etc.). Even back in the day the UART had some bus on one side that ultimately the CPU was communicating through. Today we have FTDI and other vendors that make nice USB UART solutions, doesn't make it any different some layers of interface between the software and the UART and then the other side of the UART has some interface, be it TTL/chip level or RS-232C or RS-422, etc.
Early Arduinos you often used an FTDI USB-to-UART board that also provided power to the Arduino. Some have that USB power and serial/UART on the Arduino board itself and then that is hooked up across the board to the UART on the AVR chip (same deal some processor with some layers of buses to allow software to communicate with a UART which has some interface on the other side of it, in this case the pins on the edge of the AVR, at chip voltage levels, TTL).
Since the UART functionality has not changed in decades, why should the software terminology or even software applications change at the application level? Write a Linux/Unix TTY application 10-15 years ago against a UART chip on your motherboard, and there is a good chance it still works today with a USB to TTL level or USB to RS-232C level or RS-422 or whatever pin/level definition. The same goes for Windows, and I have code that old that still works on both. In the Windows world the term COM is used.
I have not used the Arduino sandbox in a while and if so would have been on Linux, but I wouldn't be surprised if that program which is Java, if I remember right, is generic and uses the system name so
ttyS2 on Linux and COM2 on windows.
Re-reading your question this can go much further, taking advantage of the already existing amount of software that uses these API calls. Again for decades there is no reason why you can't create a virtual port in software that carries this bidirectional data down pretty much anything you can think of. UART to Ethernet is a very common one, and in server rooms where servers still very much use COM/TTY/RS-232 ports, you can have a terminal server which has a number of interfaces which you can connect to a number of servers, then Ethernet on the other side, then if you choose not to telnet in, you can install a virtual COM port driver.
Then your application on your computer thinks it is talking to a COM port, but in fact that stream of bytes is hopping onto Ethernet then hitting the terminal server, THEN, to a UART to RS-232C level (but not necessarily pinout) cables to the server and back the same way.
Sometimes there is no reason to actually make it to a real UART, for whatever reason virtualize a COM port so that software that was written for those API calls can still work. You could perhaps think about the ancient banking software we still use that has a dumb terminal to a UART interface that perhaps back in the day was hardwired or went into a modem to eventually a server. You can make it so that software still works, through various amounts of emulation including a virtual COM port that today likely just goes down Ethernet to the server as a serial stream (TCP/IP for example).