I'm using Slackware right now; a few years ago I tried Arch. I completely agree that it felt too tentative, way too tentative. You basically have to have a nervous system that's in top shape to be able to deal with what Arch throws at you - it might be this update that renders your system broken, or the one after that, or maybe the update next week, or "oh, 3 packages changed, I'll add them before I go to bed in 30 seconds."
Granted, it's not usually that bad, but the anticipation and mental preparation must be there. And, in my case, my nervous system doesn't actually work properly :) (appt. with specialist in a couple months, hopefully!) so I'm the worst-case example of where this approach definitely doesn't work - hand me a system like this and expect me to maintain it, and I'll just go NOPE. I don't have the attention span for it, you might as well have asked me to carry 1000 spiders across a room.
But, the problem with Linux is the widespread policy of fragmentation, otherwise known as "do one thing and do it well". In practice that translates to "know about one thing and know about it well," and if you read Linux soley from that point of view, IMO everyone fulfills it perfectly. Zoom out a little and take in the bigger picture, and it becomes painfully obvious that everything is compartmentalized to an incredibly damaging degree/extent.
And yet, because of this prevailing attitude, all the "system integration" attempts and efforts are plagued by their own NIH and intentional scope limitation, so everyone tiptoes around everyone else for the sake of choice, and nobody says "that's it, we need do do XYZ this way," accepts the responsibility of world domination for XYZ, and, if it's necessary, evangelizes XYZ as The Way To Do This(TM). It can be done: https://lkml.org/lkml/2011/5/29/204 (note how (a) nobody contested it and (b) it was socially appropriate to accept it due to the context - it's often socially inappropriate to do this kind of thing in Linux.)
And so, because of the lack of integration, "looking at the bigger picture according to a standard" and so forth, it's impossible to formally define my Arch configuration which differs from yours in 10 areas such that the definition succinctly represents those 10 datapoints. Rather, you'd crash into the point of irreducible complexity at n-thousand, or at best n-hundred datapoints, because nothing integrates with anything else. (No, I definitely don't have the attention span to even fathom how you'd try to begin integration work. Nuke it from space maybe? :P)
Nix and co. are trying to build superintegrated systems the only way that's currently possible: teaching the package manager about the entire system, making the package manager the source of authority (which makes high-level integration possible), and having the package manager regenerate (or at least check/retouch) everything on every invocation. This necessitates the user learn to configure their system solely by way of the package manager, but at least it means you can pass the representation of an entire system around as a multi-KB configuration file, and handing said file to the package manager on any system then waiting a while will reproduce a predictable configuration...
...for those package versions. That's the point where everything still breaks apart.
I didn't completely use to understand (is that correct grammar?) why systems just did security releases/updates, why backporting was a thing, etc. Now I do: it's so you can apply the security update yesterday with minimal eyeballing and integration testing and have a fairly confident outlook that the patch won't introduce subtle bugs or require system changes.
The likelihood is that in practice the small occasional ancillary change a security patch might introduce might occasionally require integration work or removing said small side change(s) from the patch. So effort does still need to be invested in a small niche percentage of situations. (I've always been curious about what kinds of contexts this would call for; anecdotes welcome.)
But just about every sysadmin or Linux user out there would probably react the same way if they discovered me sitting at their main workstation (possibly SSHed to their production server >:D) adding 'apt-get -y update; apt-get -y upgrade' to a daily cronjob: I would imagine 100% of them would be leaping in my direction, horrified; 90% would be exceeding their average Sound Like A Sailor quota, and about 20%-40% would be using their keyboard as a bat (with the 2% who own IBM Model Ms unfortunately succeeding).
And this is because, for any given upgrade, because nothing's integrated in a truly neural-network-analogous model - where everything can see everything else and react to it - things inadvertently step on the toes of other things because they're blind to anything except their own existence. And the problem is, there are so many different layers, the toes in question might be anything from library version conflicts, package manager confusion (dependency resolvers can reach mathematically unsolvable conclusions, requiring force-removal etc etc to fix), ABI/API breakage (because the maintainer for 'unicorn' never realized the package for 'libwobble' hasn't been pushed yet because they were using a local version), software- or hardware bug regressions, forcing users to use an older software version... the list goes on. It's not a big list, but the consequences are disastrous enough that it might as well be infinitely large.
I remember reading a long time ago how Chrome OS autoupdates on every bootup. "Wow," I thought, "that's really impressive." I'm not sure if it still does that - I expect autoupdating is a background thing now - but it's still impressive. Google has to do this since, it's practically part of Chrome, and since Chrome OS' app sandbox is inside the web browser there's no real need for system-level flexibility or additional capability, and this makes things significantly easier. The other boon is, but of course, the unique hardware situation; Chrome OS isn't something a manufacturer grabs, Google approaches a manufacturer with a contract (basically a pile of money to make Windows temporarily look slightly less interesting, I'm guessing). This means Google are largely in charge of the OS, and the impetus is coming from Google to get it working in the first place. This means the system has pretty much perfect driver support.
I ran through a Slackware-current update the other day that fell apart most delightfully when I tried to upgrade aaa_elflibs to i586 by accident. After realizing what I'd done after 15 minutes (I use both 32-bit and 64-bit machines, the former more than the latter at this point) I fixed that then figured out the original "fell apart": udev no longer existed, eudev had taken its place. Slackware will not upgrade a package not already installed.
I don't have nearly that much trouble with Arch anymore. You know when you get 3GB of updates to watch out, but the general trend in recent years has been positive - more issues have been fixed than made. My most recent one being that Dolphin can't properly save edited desktop files anymore.
There is a testing repo for a reason. If Arch had more adoption, the model can and would work, because you would eventually get enough powerusers in testing to live that life of worry the next update kills your desktop. More people would mean more packages are held for testing, and more people would mean more of the AUR packages would be pulled into community. The only potentially defective design is releasing known regressively bugged software to release channels just because the bugs don't completely break the system.
ChromeOS can sound impressive until you wonder when the last time OpenRC + the kernel broke, especially when you have Google engineers auditing and patching the Gentoo kernel to insure compatibility on their devices. By comparison the last issue I had with systemd was.... never, really. I even made it through the switch with a fully working system, I just had a lot of missing services I had to reenable.
When Arch breaks, its always either A. the graphics stack, B. Xorg and its ilk, or C. bootloader. Its super rare for a kernel to be pushed upstream that regresses wifi (unless your broadcom out of tree driver breaks), or audio, or peripheral connectivity (usb, bluetooth). Its super common that major upgrades to X or Mesa or libGL can either kill acceleration or your entire desktop period. And having switched to directly efistub loading my kernel, I haven't had bootloader problems ever. And systemd has built in gummiboot now.
I'm using Slackware right now; a few years ago I tried Arch. I completely agree that it felt too tentative, way too tentative. You basically have to have a nervous system that's in top shape to be able to deal with what Arch throws at you - it might be this update that renders your system broken, or the one after that, or maybe the update next week, or "oh, 3 packages changed, I'll add them before I go to bed in 30 seconds."
Granted, it's not usually that bad, but the anticipation and mental preparation must be there. And, in my case, my nervous system doesn't actually work properly :) (appt. with specialist in a couple months, hopefully!) so I'm the worst-case example of where this approach definitely doesn't work - hand me a system like this and expect me to maintain it, and I'll just go NOPE. I don't have the attention span for it, you might as well have asked me to carry 1000 spiders across a room.
But, the problem with Linux is the widespread policy of fragmentation, otherwise known as "do one thing and do it well". In practice that translates to "know about one thing and know about it well," and if you read Linux soley from that point of view, IMO everyone fulfills it perfectly. Zoom out a little and take in the bigger picture, and it becomes painfully obvious that everything is compartmentalized to an incredibly damaging degree/extent.
And yet, because of this prevailing attitude, all the "system integration" attempts and efforts are plagued by their own NIH and intentional scope limitation, so everyone tiptoes around everyone else for the sake of choice, and nobody says "that's it, we need do do XYZ this way," accepts the responsibility of world domination for XYZ, and, if it's necessary, evangelizes XYZ as The Way To Do This(TM). It can be done: https://lkml.org/lkml/2011/5/29/204 (note how (a) nobody contested it and (b) it was socially appropriate to accept it due to the context - it's often socially inappropriate to do this kind of thing in Linux.)
And so, because of the lack of integration, "looking at the bigger picture according to a standard" and so forth, it's impossible to formally define my Arch configuration which differs from yours in 10 areas such that the definition succinctly represents those 10 datapoints. Rather, you'd crash into the point of irreducible complexity at n-thousand, or at best n-hundred datapoints, because nothing integrates with anything else. (No, I definitely don't have the attention span to even fathom how you'd try to begin integration work. Nuke it from space maybe? :P)
Nix and co. are trying to build superintegrated systems the only way that's currently possible: teaching the package manager about the entire system, making the package manager the source of authority (which makes high-level integration possible), and having the package manager regenerate (or at least check/retouch) everything on every invocation. This necessitates the user learn to configure their system solely by way of the package manager, but at least it means you can pass the representation of an entire system around as a multi-KB configuration file, and handing said file to the package manager on any system then waiting a while will reproduce a predictable configuration...
...for those package versions. That's the point where everything still breaks apart.
I didn't completely use to understand (is that correct grammar?) why systems just did security releases/updates, why backporting was a thing, etc. Now I do: it's so you can apply the security update yesterday with minimal eyeballing and integration testing and have a fairly confident outlook that the patch won't introduce subtle bugs or require system changes.
The likelihood is that in practice the small occasional ancillary change a security patch might introduce might occasionally require integration work or removing said small side change(s) from the patch. So effort does still need to be invested in a small niche percentage of situations. (I've always been curious about what kinds of contexts this would call for; anecdotes welcome.)
But just about every sysadmin or Linux user out there would probably react the same way if they discovered me sitting at their main workstation (possibly SSHed to their production server >:D) adding 'apt-get -y update; apt-get -y upgrade' to a daily cronjob: I would imagine 100% of them would be leaping in my direction, horrified; 90% would be exceeding their average Sound Like A Sailor quota, and about 20%-40% would be using their keyboard as a bat (with the 2% who own IBM Model Ms unfortunately succeeding).
And this is because, for any given upgrade, because nothing's integrated in a truly neural-network-analogous model - where everything can see everything else and react to it - things inadvertently step on the toes of other things because they're blind to anything except their own existence. And the problem is, there are so many different layers, the toes in question might be anything from library version conflicts, package manager confusion (dependency resolvers can reach mathematically unsolvable conclusions, requiring force-removal etc etc to fix), ABI/API breakage (because the maintainer for 'unicorn' never realized the package for 'libwobble' hasn't been pushed yet because they were using a local version), software- or hardware bug regressions, forcing users to use an older software version... the list goes on. It's not a big list, but the consequences are disastrous enough that it might as well be infinitely large.
I remember reading a long time ago how Chrome OS autoupdates on every bootup. "Wow," I thought, "that's really impressive." I'm not sure if it still does that - I expect autoupdating is a background thing now - but it's still impressive. Google has to do this since, it's practically part of Chrome, and since Chrome OS' app sandbox is inside the web browser there's no real need for system-level flexibility or additional capability, and this makes things significantly easier. The other boon is, but of course, the unique hardware situation; Chrome OS isn't something a manufacturer grabs, Google approaches a manufacturer with a contract (basically a pile of money to make Windows temporarily look slightly less interesting, I'm guessing). This means Google are largely in charge of the OS, and the impetus is coming from Google to get it working in the first place. This means the system has pretty much perfect driver support.
I ran through a Slackware-current update the other day that fell apart most delightfully when I tried to upgrade aaa_elflibs to i586 by accident. After realizing what I'd done after 15 minutes (I use both 32-bit and 64-bit machines, the former more than the latter at this point) I fixed that then figured out the original "fell apart": udev no longer existed, eudev had taken its place. Slackware will not upgrade a package not already installed.