Which ones? I would like to know more about Plan 9.
For instance, GUI programs are built by reading from files like /dev/cons and /dev/mouse and writing to files under /dev/draw. Now it seems that this will end up in a mess when you try to run multiple GUI programs, but that is not the case - a WM can provide virtualized versions of these files, and each program still feels that it is using the entire screen and does not need to know about the WM at all. My description is likely not very accurate because I haven't really tried it, but you can find the whole story in the related man pages: http://man.cat-v.org/plan_9/3/cons http://man.cat-v.org/plan_9/3/mouse http://man.cat-v.org/plan_9/3/draw.
Another example is the authentication facility of plan 9. Instead of being a dynamically-linked library, it is a separate process that can be reached via IPC. Russ Cox et al have a talk on this (https://swtch.com/~rsc/talks/nauth.pdf).
This is also why Plan 9 has no dynamic linking, since those things are done with IPC instead.
EDIT: I get that Plan 9 is "more UNIX than UNIX" and that this is an extension of how UNIX behaved. I view that as a philosophical, rather than practical, point though.
Because it has nothing to do with the way other OS implements files. The kernel is effectively an I/O and network multiplexer for synthetic file systems that abstracts common resources to enable location/network transparency, single system imaging and interface uniformity. This is done through the use of the 9P protocol, and process boundaries and file system hierarchy are enforced through namespaces.
9P is cacheable, stateful, encryption/auth-agnostic and can run over any transport layer.
This actually has far more consequences than "everything is a file":
a) There are no symlinks. You don't need them.
b) There is no root or superuser. You don't need it.
c) Your applications don't necessarily need to be network-aware.
d) Remotely debugging, migrating or copying a system resource is as simple as a mount and it will just work.
e) There are no sockets. You don't need them. You have ndb.
f) There are no ioctls.
g) Networking information being a file server obsoletes the need for NAT and VPN, among other things. [1]
Then, of course, the Plan 9 userland is great. Plumbing, a compiler chain that makes cross-compilation stupidly easy (so much so that OpenBSD considered using it but backed away because of the Lucent license at the time), the acid debugger, mk, Venti, etc.
[1] http://cm.bell-labs.com/sources/contrib/uriel/slides/fosdem0...
There are plenty of attempts at these outside of P9, of course. Linux and other Unices does part of this with the /proc filesystem. Plenty of scripting languages let you access URLS like files in their IO system. File managers treat archives like directories. FUSE lets you mount a foreign system's file system via ssh…
In Plan 9 this was the core concept and didn't require special treatment. Ideally you'd build your whole user-accessible system around this.
Other attempts at unified APIs were single-language image-based systems like Smalltalk, Common Lisp or Oberon (the latter being a major influence on P9, to be polite). There function-/method-calls took the place of the file system api.
Or object-based systems, where you had an interoperable object protocol taking care of interconnectivity. Doing everything via CORBA or COM calls. Actually, Windows' PowerShell is a pretty decent combination of the old Unix UI and this.
Personally, I see two problems that really ruin things for the Plan 9 approach. First of all, "just protocols" isn't as simple as it seems. So you access your hardware device or network server as a file or set of files. Great, but what do you read and write to that? Conceptually you moved from calling a "do_widgety_thing()" function to a "DO WIDGETY THING" protocol message. API design is still hard. Just like "do everything via REST" isn't the solution to all of your programming problems.
Second of all: This aims at a high level of genericity. And in this world of the web, apps and services, that's not popular due to lack of a commercial appeal.
Under Plan 9, the tool you use to redirect output from one machine to another is just "mount": mount /dev/mouse and /dev/draw from the other machine onto this one, run the command you want, and they appear on the remote machine - no changes required to the kernel or graphics drivers or any other part of the system.
Of course, remote display is just one application - since Plan 9 exposes just about everything as a filesystem, you can mount a remote machine's TCP stack or editor session or authentication keys or even actual ordinary file storage, transparently and easily.
aux/gpsfs -b 9600
aux/timesync -G
gpsfs reads data stream from an NMEA compatible GPS device and provides four synthetic files: position, time, satellites and raw. timesync then uses the time file to synchronize local time to GPS. I can read the satellites files to see which GPS satellites were seen where and their SNR etc. The entire gpsfs program is under 1200 lines of C. The point being, it is fairly easy to provide such an interface for new devices. Since it is "just" a filesystem, standard systems tools can be used with them -- you don't have to teach them new tricks. Not everything fits in this paradigm but a surprisingly large number of things do.
Simplicity is a virtue only if you take it seriously.
Someone else mentioned that plan9 features are steadily being added to Linux but that misses the point entirely. Adding a set of simple features to a complex system makes the system even more complex as now you have even more things that can go wrong.
Can I append <data> /dev/mouse ?
Sharing {open,read,write,close} interface, but with exception and different semantics leads to a weird flavour of genericity.
That's actually the easy case. Remote files are not local files, but local files are remote files: or more precisely, local files are a special case of remote files from the point of view of file access. If your filesystem API starts with the assumption that files are remote and must be handled as if they are remote, then you get pretty good local file access for free, as HTTP has been demonstrating for a couple of decades now. Of course if you instead start with the assumption that files are local and thus it's safe to do blocking I/O on them then when you add remote files you'll end up with an NFS-like mess instead. That doesn't prove that abstraction and generalisation can't work cleanly, it just shows that you were looking through the wrong end of the telescope. (Really, the distinction here isn't truly between remote and local but between unreliable and reliable. All remote file access may be unreliable, but it's certainly not the case that all local file access is reliable, or should be expected to be reliable. Especially not when you bring in user-space filesystems, as Plan 9 does.) Apparently Plan 9 actually started with a blocking-I/O-plus-thread-spawning model which was only so-so before it was fixed up: http://pdos.csail.mit.edu/papers/plan9:jmhickey-meng.pdf .
On Plan 9, network sockets are available via the /net filesystem (for instance, /net/tcp and /net/udp). If you use the standard remote filesystem mechanism (9P) to mount a remote system's /net filesystem, you can access files there to create sockets from that system, rather than your local system: VPN with just the filesystem.
If you want to forward a few specific ports from that system to yours, mount the relevant bits of your /net over the remote system's /net: port forwarding with just the filesystem.
If you want to prevent an application from accessing the network, or firewall it from accessing certain ports, you can limit its access to /net or a subset of files in /net: firewalls with just the filesystem.
It's very useful because uou don't need a C FFI to access OS functionality, graphics libraries and the like. Any language whose implementation allows you to read and write files can already do a lot of things (including GUIs, IPC and so on). There are very few wheels to reinvent. Furthermore, any program that wants to integrate with yours also needs to do nothing other than open, read, write and close files. You can expose any function or configuration variable of your programs through files -- and all you need to do for that is to read and write byte or UTF-8 streams.
Things go a bit further than just "IPC is done by reading and writing files". It's only one of the principles behind Plan 9's approach to files and filesystems.