That's a very large question, but I'll take a stab at a quick summary.

- All resources in Plan 9 are accessed through the file system. Want to get a screenshot? Read from /dev/window. Want to get access a file on a machine halfway around the world? Mount it on your file system. Want to interrogate the kernel, or change things? /proc. (this last bit has been ported to Linux and other Unixes; only greybeards tend to remember the days when ps had to be setuid root)

- (almost) all resources are textual. None of this business of sending obscure bits to ioctl; if you want your connection to be a certain baud, you open the appropriate "file" and tell it so.

- Related: none of this connect, bind, nonsense. You want network sockets? Open stuff in /net.

- There is no one single "file system", unlike in Unix. When you are running in a 9term, /dev/cons is the console. When you are typing in a different 9term, it's still reading from /dev/cons but it's a different /dev/cons. It's possible for every program on the system to have a completely different view of the filesystem (although I doubt it's really sensible). Accordingly there's no superuser; there's only "permission to access X".

- Union mount points. There's no /bin, /usr/bin, $HOME/bin, etc; everything is always in /bin. The system automatically makes /bin contain the executables that are most appropriate fro your processor; rc is always /bin/rc but on one machine it's MIPS code and on another it's x86 code.

- A resulting truly distributed system. Typical use had you logging in from a network terminal (like an X terminal) and running jobs on a CPU server mostly transparently, there's disk servers you can mount, etc. I'm not 100% sure how this part works, because I've never been able to run it in the wild.

- Plan 9 was designed with the intent of GUI stuff from the get go. There's no curses stuff, no console libraries; if you want to do that stuff, you use a GUI. But these GUIs were designed by folks who were very comfortable with using a command line, and so one ends up with huge amounts of text on screen that you interact with (the history mechanism for rc actually looks at the window buffer for the terminal it is running in, looking for prompts). There's an input language for mice, that's most obvious in acme (where cut and paste are done by mouse button chords).

- As a result of this most of userland has been worked over, probably because somebody was forced to think seriously of reimplementing the Bourne shell. rc is remarkably minimal for a login shell in this day of zsh, and seems useless in an xterm; but because in a 9term you can edit previous output and previous command lines and tell the terminal not to send input at the end of a line but instead wait for you to decide you're finished it ends up being surprisingly powerful and usable. It's hard to get this in Unix because a lot of the tricks they did with it involve accessing the textual representation of the contents of the 9term and e.g. grepping over it or the like. Plan 9 from User Space does manage it and it's a very strange experience.

- Unicode throughout, which doesn't seem like such a big deal now but was pretty significant back in 1992.

- A bunch of fascinating programs written as a general solution to specific frustrations. Modern terminal replacements sometimes highlight URLs or the like; the Plan 9 plumber would do this with anything, and was consistently implemented across the system (Button 3 in recent acmes, for example, runs the plumber and only does local search if that fails to match).

Plan 9 can be very disturbing to work with at first; everything seems incredibly primitive, and it has a very minimalist feel to it, but when you get used to the idioms it can be incredibly powerful. It's a pity they never wrote a real web browser for it, I would love to see what it would look like. The whole experience is very strange, and yet there's a certain elegance to it.