Becase basically you just need to know one set of APIs, this time the file open/close/read part of your C library. The rest is "just" protocols. No arcane calls

Becase basically you just need to know one set of APIs, this time the file open/close/read part of your C library. The rest is "just" protocols. No arcane calls to open sockets or query mice, you treat everything like a file-handle. 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.