> Plan 9 had two major ideas, that everything else was built on. The first was the idea that everything is a file. You might think that in Unix everything was already a file, but it was only partially true. In Plan 9 they took this idea to the extreme. Everything including the input and output of the system, process management and network connections were all accessed through the file system instead of the usual syscalls.
Historically, Unix has had two main APIs for establishing TCP/IP connections - Berkeley sockets, and the AT&T Streams-based TLI (which later evolved into XTI). In Berkeley sockets, although a socket is a file descriptor, you can't create one just using `open()`, you have to use the `socket()` system call instead. Whereas in TLI, a network protocol such as TCP is actually a device file (e.g. `/dev/tcp`), and you create a socket by opening it – although instead of `open()` you have to use `t_open()`. Arguably, TLI is closer to "everything is a file" in this regard than Berkeley Sockets is. Alas, Berkeley Sockets won and TLI lost. TLI was more Unix-like because it was invented on Unix; Berkeley Sockets was copied from TOPS-20.
Originally with TLI, `/dev/tcp` was an actual device file on disk. In principle, you could have an alternative TCP stack using some other name, e.g. `/dev/tcp2`, although I'm not sure if any systems ever did that. The later XTI standard moved away from "everything is a file" by stating that `/dev/tcp` didn't actually have to exist in the filesystem, instead the kernel could just interpret `/dev/tcp` as an opaque string requesting the TCP protocol.
`/dev/tcp` in bash is possibly inspired by TLI but uses Berkeley sockets, and I don't think TLI ever let you do `/dev/tcp/HOST/PORT`, instead you had to use `t_bind()` to bind and `t_connect()` to connect. I wonder why Linux/etc never added support for bash-style `/dev/tcp` (and `/dev/udp`) in the kernel so other programs could use it. Nowadays, I suspect many would object to that on the grounds that it could potentially be abused into a security vulnerability.
z/OS is unusual in supporting multiple concurrent TCP/IP stacks, and technically being a Unix (it is certified as one). If you have more than one TCP/IP stack, you can control which one your application uses by setting the `_BPXK_SETIBMOPT_TRANSPORT` environment variable, or by calling the `setibmopt()` API on the socket. If you don't do either, z/OS extracts the routing table from each stack and uses that to forward requests to the appropriate stack by matching the IP address against those routing tables.