Sure. In one sentence. I thought it was crystal clear already. So here goes - to wit: Upon activation of The SegWit Omnibus Changeset, previously fully-validating nodes are rendered non-validating nodes, as they are incapable of validating SegWit transactions.
Pedantically, this is not correct. They validate many things about them-- locktimes, spend consistency, prevention of double spending, fees, non-inflation. The only thing they don't validate is segwit signatures. However, they also also drop and ignore segwit txn unless they're in blocks-- they won't relay them, or mine them, or show them as unconfirmed transactions in wallets. Non-upgraded nodes also know something is going on about that they don't understand and will tell the user, and if you wanted to set yours up to shut down until you upgrade it to be segwit aware you could-- though it would be an unusual thing to do. (Except "Bitcoin Classic"-- they just started ripping out the notification logic because it was telling users they were out of sync due to CSV's pending activation-- rather than just integrating this long coming, well understood, simple script addition that we already wrote for them...)
The same non-checking of the new thing but still checking the old stuff was is true for CSV which will activate soon, it was true for CLTV, it was true for P2SH, it was true for nlocktime by block-height back when Bitcoin's creator added that. This particular upgrade mechanism is an intentional part of Bitcoin's design with specific affordances in the transaction structure and script system. It's one that has been used many times in the past without trouble via a process which has evolved and matured in response to experience (in the above listed changes as well as a number of additional ones).
Before and when segwit activates your nodes will tell you (unless you're running the most recent "Classic" software...), at that point you can figure out what you want to do.
The obvious thing to do is to upgrade-- but you don't have to: things will continue to work and if you are already requiring multiple confirmations to consider transactions confirmed or primarily sending funds it's hard to argue that your security would be in meaningfully degraded. If you'd like to upgrade but you are running customized or un(der)maintained software (like Bitcoin "Classic", or one of the many abandoned full node implementations) you can get the full security effect of upgrading by setting up an upgraded node and then -connect-ing your non-upgraded node to it. This means that you can upgrade on your on terms, when it fits your schedule, and in a way that minimizes costs and disruption to your activities. It means that, if you want and/or your process requires it, you'll have all the time you need to have new software audited to your requirements or to forward port and test your customization. Of course, you'll likely just upgrade-- as it's easy to do, and after doing so you can get the benefits of using segwit yourself but when and how you upgrade is up to you and on your terms. And that is really how it has to be: We can't build a system who's value proposition begins with personal freedom and autonomy with a system maintained through coercive synchronous forced upgrades.
What if the number of bitcoin users increases by by some factor due to new entrants, and a few of them fire up nodes, such that absolute node count rises while percentage drops?
This is an effect that was reasonably expected in 2011/2012 which has been thoroughly debunked by experience. The user count has grown astronomically while the node count has declined pretty much right along with the increase in the initial sync time. More users means more nodes, but not when running a node makes your systems obviously slower, chews up enough bandwidth to run you into data caps, and takes a week to sync up. In Core we've been working frantically for years slamming out performance improvements to try to use optimization to compensate for load increases to protect decentralization.
Segwit increases capacity, but does so in a way that can eat less into those factors than a simple blocksize increase-- because it is a true scalablity improvement-- and it sets the stage for further efficiency increases down the road. Today even many big name bitcoin businesses outsource their node operations to centralized APIs, and this was something that no one working on Bitcoin really anticipated in 2011.