(Sorry for dropping this, lost available time)

I see your point.  OTOH, use of SNI needs to be something that can be 
disabled and people need to be able to connect to host A while supplying 
host B, not necessarily using IP addresses for the specificity.  Use-
case example: someone has a service "www" hosted on ["www-1", "www-2", 
"www-3"].  They have an SSL certificate for "www" and they want to have 
a health-checker which probes for "working service, all certs valid and 
not about to expire".

Unless s.connect() gains a keep_original_hostname=False option (?), this 
is hard to do.

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.

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?

In which case, if the default is to change, the API should be sorted 
now, so perhaps connect() should take an override_server_hostname=False 
flag, which will make it pass the connect() hostname parameter instead 
of self.server_hostname in the call to _ssl.sslwrap()?  With checking 
for an IP address?