For me, 1Password wifi syncing (with local vaults) never worked quite right, and I don't think that feature has been touched by its developers in all the years since I first bought a 1Password license. It's never going to be. They're all in on their own cloud service and subscriptions.
I don't hate 1Password for using subscriptions -- that's their prerogative -- but I wish I'd known they were going to bail on the Mac-as-digital-hub architecture. That was 100% why I bought it.
I'd describe that pivot, too, as a communications breakdown.
While this might be true in general, one of the main advantages in choosing FOSS is that features used by a small subset of users are more likely to be kept than for proprietary software.
When a software package starts out, early-adopting power users build its popularity and help shape its growth ... until the package becomes so useful that it is now marketable to the masses. Then, for proprietary software at least, there's a strong incentive to streamline and remove anything the masses don't care about...which can alienate the same people who helped make their package great.
For FOSS, there's powerful motiviation to retain features that even only a handful of power users rely on -- lest that project be forked.
I can't remember the last time I've been feature-burned by a FOSS project. My feature-burn scars for proprietary software, however, are many -- and at least a few are quite deep.
You're right though, most FOSS seems way less likely to remove features people actually depend on that most proprietary software.
Developers should stick to implementing features they're likely to maintain.
If there is an obscure setting somewhere which makes something work well for you while you become a minority of users in the process, you would not use it?
>I never want to be outside of the primary use case.
You've extrapolated too far from their statement. Most people have probably been in this kind of situation and most of us have probably been burned by it at some point: Use a product for an edge case of its intended function and you risk losing that functionality at some point.
Vendors will generally cater for the masses. Where possible, avoid building your usage model around niche features. Assume that free products/features are a loss leader and will disappear at some point. Have a contingency plan if the at-risk feature is particularly important to you.
Depending on what you mean by "in some future update" and "pretty much guaranteed" (given an infinite timespan everything will disappear) I don't think that's true. I've kept my Firefox user.js (my manual about:config changes) under git over the past 3 years, and of the 44 options that I customised, 36 are still present and (seem to be) active.
6 of the about:config user_prefs customised add-ons, so they no longer work due to the shift to Webextensions (but I can still make 5 of the customisations via another interface).
1 customised the GCLI, which was removed, and 1 customised Panorama, which was also removed. (However, most of what GCLI did, can be done some other way, and there are a couple of Webextensions faithfully emulating Panorama.)
 The file is older, but I added it to git only three years ago. Hence, many of the about:config changes have been "alive" for longer, but I have no record of those that were removed earlier than 3 years ago.
 Cursorily glancing through my comments above each entry to make sure that it still does what it was supposed to.