This behavior is not limited to just segwit but in general for node services; it just happens to be that segwit is the only major node service right now.
Not quite-- NODE_NETWORK exists, and is absolutely required for outbound connections (e.g. doesn't even get the bypass for 40 connections).
In whatever release that comes out after segwit is required NODE_WITNESS will become required just like NODE_NETWORK is. The purpose of outbound connections is to make sure you aren't partitioned and can obtain blocks, they're for your own benefit. Inbound connections are for the benefit of others.
It's not acceptable for the network topology to suddenly change when segwit activates-- can you imagine that? drop all your current connections and then form new ones hoping that the network can make a non-partitioned graph?-- that would be irresponsible. Instead, it changes its connection preference at install time, so if there were any issues they could be addressed while the user is paying attention.
Oh you've never heard of that 95% rule?
That's rather interesting, you seem to almost be saying that you can't connect to non-segwit nodes at all with that comment.
Otherwise there would be a problem if it activated and you were connected to non-segwit nodes ...
Well that doesn't match anything else anyone has said ...
If you addnode a non-witness peer, it will be accepted just fine. Any inbound non-witness peers are accepted fine. If it's not able to get connected to witness peers it'll connect out to up to 4 of them so to avoid being partitioned if there are no witness peers available. It isn't "blacklisting" in any form-- my own 0.13.1 nodes have 82 out of 118 and 71 out of 113 peers which are not 0.13.1. (and in the latter group one of those 71 is an outbound connection to a 0.12.1 peer, FWIW).
None of it impedes the ability of non-segwit nodes to operate. This was discussed in several public meetings and documented. I'm not aware of any problems resulting from it, besides the usual giving Kano something to howl abusively about. When Bitcoin XT merged "xthin" it incorporated something far more aggressive (an absolute prohibition on outbound connections to non-xthin peers, even if addnoded, even if the node was partitioned)-- yet as far as I can tell there has been narry a complaint from Kano about it.
You keep throwing around this word 'partition'.
You forgot that 95% is required?
So, anyone who doesn't accept incoming connections and only makes outgoing connections with 0.13.1 ...
--
Heh, why would I need to complain about something that, for all intents and purposes, doesn't exist

I've never sided with XT

I have posted against it

The one I did side with was BIP100 - that turned out to be a bitcoin dev scam - no intention of ever adding code to vote for it, even though around 70% of blocks gave 'comment' voting for it and a vote implementation would very likely have gone to acceptance. It didn't suit the bitcoin dev's pocket financial requirements like LN does
