It's really not. Imagine a file system where all the "real" file locations are hidden, and the visible file structure just symlinks to these "real" locations. Practically no overhead at all. There will be a minor performance hit with uncompressing files before starting a program, but that's about all.
> Actually, they're nothing like a traditional UNIX package manager, because they don't handle dependencies. They're application bundles (ala Mac OS X) with a store front-end.
My point was in terms of usability. The average user does not care about dependencies, nor do they need to care about them, even when using a package manager.
> The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all.
That only works when all applications are written using those standard libraries, and that doesn't always happen, even on OSX. Why punish software developers for wanting to use libraries that better suit their needs?
>a system that was originally built as a successor to the original Mac OS.
The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted, but when it came to OS design they took ideas from many places, not just MacOS. As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past.