This problem seems to be due to missing support for IPv6, and not simply specific to CoreFoundation. If there is not an IPv6 listener in addition to the IPv4 listener but the connecting process does not understand the need to fall back to IPv4 (i.e. 127.0.0.1) after the IPv6 (i.e. ::1 ) connection fails, the result is that broken pipe.

This is lower level than CoreFoundation. SSHd will not resolve localhost properly when setting up SSH tunnels.

I'm wondering if this also has to do with why I can set the mysqladmin password but not the mysqladmin localhost (hostname) password

And yes, root access is enabled on my machine.

Everyone should understand that localhost is a symbolic name, it is not hardwired into your OS, it is looked up using DNS just like any other symbolic name. Depending on your DNS settings (and your ISP if you have your DNS set to use your ISP's services) localhost may or may not resolve. It is up to the DNS server to have an entry (and reverse entry) for localhost. If that is missing, localhost just plain won't work as you expect.

127.0.0.1, on the other hand, is essentially hardwired. There is a special network interface for 127.0.0.1 that is the 'loopback' net that knows packets sent to 127.0.0.1 are for itself.

It is up to the DNS server to have an entry (and reverse entry) for localhost. If that is missing, localhost just plain won't work as you expect.

Hopefully not. Every machine that needs TCP/IP name resolution of any sort SHOULD have its own local entry or entries for localhost in whatever local name resolution mechanism it uses. For example, MacOS X has a file at /etc/hosts that is used in single-user mode (and in fact during boot before networking or NetInfo is up) and the default NetInfo entries include localhost entries. Not having such entires locally is a very serious security hole because it would let a DNS server tell you who you are. I have seen people cause serious trouble by removing their local mapping of localhost or making it subsidiary to what DNS says.

What is happening with these failures is that at some point whatever process is asking for name resolution is getting back the IPv6 address for the loopback (::1) as the address of 'localhost' and trying to use it for a connection that cannot be made because there is no IPv6 listener for whatever it is trying to connect to. The program SHOULD then look for the other address for localhost (the IPv4 address 127.0.0.1) and connect to that instead, but some (many? most?) programs don't anticipate that particular failure mode and simply fail because the first connection failed.

If you want to see proper recovery in action, try 'telnet localhost 22' and note the success (if you have SSH on) then try 'telnet localhost 80' and note the initial failure and then success (if you have the web server running.)