A few, off the top of my head:
configd: A configuration store that handles storing (and monitoring changes to) configuration. It supports arbitrary plugins, such that other dependent systems can inject their own implementation code if necessary. It depends on kernel notification APIs and network notification APIs that are implemented at a different level.
launchd: Starting/stopping/restarting services, on-demand and on a schedule, per-user and system-wide.
diskarbitrationd: Handles mounting/unmounting of file systems, and notifies clients of changes to mounted file systems.
opendirectoryd: Handles namespacing of local and remote user/data directories. This includes LDAP, local user accounts, etc.
mDNSResponder: Used to be just the mdns daemon, now handles all name resolution and local caching.
All of these things have been iterated on independently over time, are loosely coupled with each other, and do not create tight bindings between Mac OS X and open source software, nor do they require huge non-portable changes to open-source software.
The precursor to opendirectoryd was netinfo, which also used to handle name resolution and caching. Later releases of Mac OS X moved name resolution into directory services, and then eventually into mDNSResponder. launchd replaced system starter (similar to initd/rc), cron, and a number of other services, but maintained 'perfect' backwards compatibility with the standard configuration file formats (eg, crontab(5)).
These are just a few of the (independently maintained, internally) projects/daemons that Mac OS X layers together to produce the desktop. You don't need a huge monolthic project to tackle all these problem domains, as evidenced by the fact that Mac OS X works.
You also benefit from laying these projects cleanly, as it allows them to tackle what they're good at, provide a stable interface, or even be swapped out entirely later.