Hey Phil,
> (Sorry for dropping this, lost available time)
know the feeling :-(

> use of SNI needs to be something that can be disabled
maybe. See small rational below:

> and people need to be able to connect to host A while supplying host B
This seems to be a fringe case for usage and I seem to thing adding this
would overly complicate the API. When testing hosts you would have all
the names in DNS I'd assume.

> Unless s.connect() gains a keep_original_hostname=False option (?),
this is hard to do.
Is this starting to look too complicated?

Options for client side SNI:
1. wrapssl() - defaults to SNI enabled on SSL2/TLS1 connections (compile
time/module level/object variable disable if really needed?)
2. wrapssl(server_hostname=True/False) - enable SNI using the connect
hostname (if domainname and not IP/socket)
3. wrapssl(server_hostname=True/False/String) - True - enable SNI as
above, False/None- don't use SNI or use hostname if a String.
4. wrapssl(server-hostname=String)
5. connect() should an override_server_hostname=False
more?

> Then there's the principle of least surprise -- while it would be nice
to get SNI working automatically for everyone, it's still plausible that
amongst the various TLS servers out there are some which break horribly
for SNI and upgrading Python shouldn't break the tools in use.

Small rational to enable SNI by default:
1. SNI probably won't break too much stuff.
It was only in July 2009 that Apache-2.2.12 got officially released with
proper SNI support. Patches existed before then however deployment was
limited. mod_gnutls did implemented this earlier however I never thought
this was widely used.
Vista IE7 got SNI support in ~2005
(http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx)
FF got SNI support in the 2.0 release (October 24, 2006, wikipedia) 
(https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26)
The OpenSSL server side API for SNI required the registration of a
callback to receive the SNI name. It is possible that there are some
faulty implementations in this part of the server code. The default case
that a TLS server doesn't account for SNI is very safe as it won't ever
get a callback for it.
The existence of wide spread client side support with limited server
support hasn't broken the web.

> So I tend towards favouring "make use of the newer, less well tested, 
protocol feature something that has to be explicitly enabled", even if 
it adds a line to boilerplate -- if SNI ever takes over the world (as 
Host: headers in HTTP have) then it can be defaulted on in future 
perhaps?

2. I think with p3k there is an opportunity to put something in that may
break stuff. The release noted didn't guarantee stuff would work compatibly.

3. supporting SNI clients by default may actually break less stuff that
not supporting SNI client. e.g. Webhosting companies may embrace the SNI
features of Apache for maximum IP utilization breaking the non-SNI aware
clients (which won't be the majority of web browsers).

> With checking for an IP address?
To be RFC compliant IP addresses shouldn't be used in SNI. Apart from
socket family checking (AF_INET/AF_INET6) and doing a regex on the name
I couldn't see an easy way to do this even looking at the low level
socketmodule.c file. Maybe I need to look deeper. I could cheat and look
at the Firefox crypto (NSS) code though.

just my current thoughts