To do that, you need to use a driver that translates between a file: and ip: (or ethernet:, tcp:/udp: or network:, allowing binding at different levels of the stack), because the protocols allow different operations. Said driver of course runs in userspace (because microkernel) and already exists. (Because it's absolutely needed for development.)

> driver that translates

That's something new... So, for the N-th device type in addition to the device driver I might need 2*(N-1) translating drivers!

Most of those would be meaningless, or require enough decisionmaking that the program between them cannot reasonably be called a driver. What kind of driver translates between audio and window system objects?

In any case, you only need 2N for translating both ways between file: and whatever: to get the same experience Unix does, and wherever that makes sense it is usually provided.

The win is of course that each of those protocols can be strongly typed and provide exactly all the operations that make sense for that protocol. Basically, think of all the things IOCTL does and give them their own names.

Ioctl was a horrible mistake, since it prevents configuring and introspecting devices with general interfaces and ad-hoc scripts.

This elevates the mistake, and polishes the worst of the early Unix conceptual fuckups.