OS X design is still a horrible mess, a monolithic BSD kernel bolted on top of a monstruous Mach 'micro'-kernel. Not to mention things like the new XML-based init system, property list files, hacks around 'extended attributes' (or whatever they call them) and many other aberrations.
Property list files: a big f*n win compared to the ad hoc mess in a Linux/BSD /etc directory.
Hacks around extended attributes: any reason not to like those? Or just because in 1977 a file was just a file, and that's the way it should be, god damn it?
XML-based init system: a sane init system. And XML added in for standardization.
OS X is a mess in several ways, but those are not it. And the "monolithic BSD kernel bolted on top of a Mach 'micro'-kernel" sounds like a win-win situation. Monstrous why? Because it doesn't fit some idealistic model?
Last year I even discovered a kernel bug in their file descriptor passing implementation that, AFAIK, still isn't fixed. Various signal handling properties are more buggy than on Linux.
TCP_NOPUSH is broken, too - if you enable it and then later disable it with setsockopt, it doesn't immediately send any pending data (as it does on FreeBSD, and as TCP_CORK does on Linux).
IIRC, a lot of their code came from FreeBSD back in the day. I wonder why they didn't keep it in sync?
It's a mess because there are several ways to do the same things, and no two things are done in the same way. It feels like any time I want to do something new in OS X I need to learn a new system of some kind. That is bad design. It should just be obvious.
If "obviousness" is the criteria for a well-designed OS, I'm not sure we've seen a (successful) well-designed OS in the history of computing. OS X certainly doesn't deserve to be called out. :)
Actually, I think it does. OS X is a horrendous frankenstein of several different systems with different design philosophies. It is really, truly awful. (Although it works - I'm using an OS X machine to type this now.)
One of the great things about Plan 9 is that everything implements the same interface. If you can interact with one thing, you can interact with everything. Using new parts of the system becomes obvious because you already know the interface.
A concrete example of why this works: In Plan 9, process information is available via (guess what) the file system, so the Plan 9 debugger just reads the state of running processes from those files. Because file systems are automatically exported over the network (also part of the file system), you can debug a running process on another machine without the debugger knowing anything about the network. Nobody had to implement network debugging - it just worked right away because of good design.
You know you have a good design when these kinds of complex behaviors just "fall out" without any additional work.