A note of caution: I personally arrived here because PlanNine fails at NoApplication. While it's true there are some wonderful things you can do with PlanNine's filesystems, many tasks are far more work than they need to be because there's no consistent structure for passing data around. PlanNine users say "It's all just text," but that's merely an abdication of thought. Communication must be structured to be any use at all.
A multiplicity of languages is a large part of the problem. Different or similar, none are exactly alike. None of the actual interpreters cover more than one small part of many jobs, except perhaps awk (which hardly seems to fit with the rest of PlanNine). Because "It's all just text," every file which receives data has its own parser, which means its own language, however small it may be. Where there is any semblance of consistency, it's tokenize(), which barely does anything. It just splits up words like the shell does, with the same way of quoting, so for example you need layers of nested quotes just to start any but the most trivial of shell commands in a new window!
Then, the text editors themselves are applications. While two of them may be piped and the third has a filesystem, they are very much distinct applications. (So are the various interpreters which the user is supposed to use together.) The Sam text editor has its own clipboard, making pasting into or out of it a pain. The Acme text editor is more convenient, and very powerful with its program launch facilities, but every graphical program has to be aware that Acme's file system conflicts with that of the window system.
Ultimately, PlanNine is all about extending applications and finding new ways to use them, not doing away with them at all. Even kernel components such as the network stack are treated as separate programs with their own distinct filesystems.