Plan 9 from Bell Labs is the operating system that the inventors of Unix (Ken Thompson and friends at Bell Labs) went on to create in the 90's. They created Unix in 1969 and released it to the world in 1974, and worked on it for another 10 years or so before AT&T pointy-haired corporate morons took it away from them and made System III and System V and so on and shattered proprietary unix into a thousand pieces, which the then sued.
Meanwhile, the actual _engineers_ at Bell Labs (led by Ken Thompson) started over from scratch in the late 80's and did a brand new OS where everything is text, everything is networked, and everything really IS a filesystem. It's kind of cool, in the same way that BeOS was cool: I'm sure both of the people who use it are thrilled. They open sourced a version of it ("inferno") long after anybody was ever going to care. At this point, it's too late to be more than a source of ideas.
However, one of those ideas is the Plan 9 protocol. The OS made no distinction between local and remote programs, because everything was networked. And everything was a file: to ask the OS to do something, you opened a file and read from or wrote to it. (Like /proc only even the system calls worked that way. You spawned a new process by opening a file.) So they _had_ to have a very efficient, lightweight protocol for remote file access that could work over any bidirectional pipe. (Which covers network socket and serial port and ssh tunnels and so on.)
So the Linux guys implemented a way to mount these suckers, as the p9 filesystem driver back around 2.6.14. Alas, the first pass didn't implement Unix semantics, because Plan 9 didn't. The Plan 9 OS design didn't use numeric user IDs but always identified things by username, and didn't have SUID or the sticky bit, and so on. Great ideas (much simpler security model, and Linux's shared subtrees stuff was inspired by Plan 9), but it's not how Linux works. The Linux guys eventually broke down and retrofit Linux semantics onto the thing as an extension. Think of it like the Linux extensions for Samba, except the base protocol is kind of nice rather than being an eldrich horror capable of summoning cthulu.
Meanwhile, the limiting factor that's been keeping people from USING p9fs is the lack of decent servers. So what if you've got a nice filesystem driver: there's nothing to _mount_ with it. The kernel's documentation for p9 says that to test it you boot a copy of Inferno (the open source Plan 9 release), which is silly. It also mentions a Linux userspace server which has no documentation or web page, builds without ./configure, and has no way to specify which directory to export. (Bravo. I don't know if this is a lack of documentation or a lack of implementation. In either case, it's a bit unripe. The standards documents for all this stuff are apparently still being written, and in flux.)
But, it turns out (paper, slides) QEMU has a p9fs server built into it. (It's not a HARD protocol to implement. If I had twice as much free time I might take a swing at doing a P9 server for busybox.) At least the development version of QEMU in source control has one does, which got merged in April 2010. The qemu documentation on this thing (inexplicably called virtfs) is still a bit sketchy in places (it doesn't mention the need to switch on CONFIG_VIRTIO_PCI). And at the moment write support seems to be broken for me. But I was able to mount a directory from the host system and cat a file, which is progress.
Once I get that a bit more reliable, I can see if it needs containerizing. :)
Oh, did I mention that a standard userspace daemon exporting a P9 filesystem has been made to scale to about 2000 clients? The report didn't say that was the server's limit, just how many that installation had...
(Yeah, yeah, I know I'm supposed to be working on NFS instead of trying to help along technologies which could conceivably obsolete it. But it's Saturday.)