Appendix C: Crazy stuff? I would beg to differ.
Basically, the Mac OS X Installer was designed to appeal to the general Mac public. Mac users expect an application to install where they can see it and not spread out over the disk in various directories. Even Apple is careful not to put everything in a standard "unix" directory structure (though there is no such thing as a standard unix directory structure).
The other problem with putting stuff in unix dirs like /etc or /var is that the directories are hidden in the Finder. Also, during a Mac OS X migration from machine to machine, Apple's installer will not migrate those unix dirs. Most Mac users aren't going to understand why their Plone install breaks on their target machine after migration if we were to use the "unix" dirs.
We've debated on whether we should have a GUI controller or not. A GUI controller is a good eye candy piece, but if we really want to make an effective controller, we feel it should be a web based controller so that instances and configuration can be done remotely if needed. We'd also like something that could be utilized on all Plone installations whether it's Mac, Win, Unix, etc. However, we haven't gotten to the point of spending the time to develop such a thing.
We also put the Mac OS X Installer together in such a way that multiple instances could be supported in an easy, straight forward manner. In addition, the Installer structure supports new upgrades of Plone, Zope, and Python. All three are totally self contained within the install and not dependent on the version of python installed in Mac OS X. This sort of support is important to production level systems. If Mac OS X is upgraded, the installed Plone should continue to work and not break because of an OS upgrade.
All of these decisions were to make sure the Mac OS X Plone installation would feel like a retail level product out of the gate. It's also designed to what we feel is an "enterprise" level. The product should work out of the box, should handle multiple sites in an easy to configure way, should not break if an OS install occurs, should not hide in any murky areas of the OS, and it should all be visible in one place.
There are other things we'd like to add to the Installer, but we haven't done so yet.
The other advantage to using the standard installer is that it's been tested by thousands of users.

