> Well, that makes it the user-specific equivalent of /usr or /usr/local.
> Do you put your configuration files in /usr/local ? Why put them
> in .local ?

Yes, software built for /usr/local will often respect /usr/local/etc in addition to /etc.

Also, many desktop Linux applications put state into ~/.local/share/$appname.  I am not sure about "configuration files", (apps that use ~/.local will typically use ~/.config for configuration, but that is a different thing entirely) but autotools applications built with '--prefix ~/.local' will often respect ~/.local/etc.

> I agree with Ned that neither ~/.local nor /etc are a good fit for OSX, 
> sadly enough I wasn't paying attention when ~/.local was added as python 
> already had a per-user directory on OSX: ~/Library/Python.

I argued loudly for consistency in treatment of UNIX-like OSes when this decision was being made, and I stand by that position.  Why would you want to break software that works fine on BSD and Linux by requiring that it specifically test for OS X, and do the exact same thing, but in a different directory?  (See <http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>)

The addition of a per-user directory on OS X when there were no similar directories on other platforms was a weird oversight.  The user site directory in Python 2.5 and earlier does not use any features of OS X and refers to ~/Library/Python only by convention.

Plus, that convention didn't support the distutils properly anyway: if you put your library code into ~/Library/Python, where are you supposed to tell 'setup.py install' to put script files?  With ~/.local, it's obvious: ~/.local/bin.

The real OS X convention is to put your code _into your application bundle_, after all, not into random directories in ~/Library.  If you don't have an application or framework bundle, you have one foot in UNIX-land already.

The point of honoring platform conventions is to provide a consistent experience to users; some users on OS X will be expecting UNIX-like behavior, some will be expecting Framework-like behavior, and there is really no reason not to provide both.

There is no reason not to consider /etc, for that matter.  PHP, for example, still reads /etc/php.ini on OS X.