I get what you're trying to say, but this assumption that only a subset of developers need to know how to write code intended to be consumed by third parties is the reason why stuff needlessly breaks all the time for no good reason. We can't have modularity without having code consumable by other components, and knowing how to write reusable components and reusable interfaces is a core competency in software development.
For a lot of use cases, a plain C API wrapper is still very useful because it’s so easy to call from practically any other language. It can be better for maintenance to have a very narrow C API than to expose all the bells and whistles from C++ wonderland.
But honestly, people seem to get all hung up on C++ having weird features. No-one is being forced to use a feature just because it exists. I use the sub-set of C++ that I'm familiar with and grow it when it looks like it'll save a lot of effort relative to cost of learning it.
So... time to move to Rust then?
It's ok if you opt to not jump onto the latest and greatest, specially at the interface level.
What is counterproductive is to not learn new features, and know when and when not to use them.
It makes absolutely no sense to stay stuck in C++11 when there's a heap of basic features that were since made available throughout the last decade.
It's even more critical the fact that the C++ standardization effort placed a great deal of effort on vocabulary types, which by its own definition mean types excpliticly designed to be used in interfaces.
It's perfectly ok to make a call to not use exceptions, template metaprogramming, multi threaded support, etc. What's counterproductive is staying stuck way back in 2011 because you do not know what's out there.
It is an ease-of-use improvement as much as a modularity improvement and provides some evolutionary pressure to design better interfaces to modular code.
I don't think so. There are multiple books dedicated to the topic of writing modular code, including books specialized in C++. Projects such as Qt are renowned for having adopted architectural traits that ensure they do not break compatibility even following a major version upgrade. I still see projects not respecting contracts and what not to put in the interface.
I think that this belief that "anyone can write clean and modular code" contrasts with reality, and suggests a certain obliviousness regarding the problem domain.
But if you know about them, maybe next time you have a problem that it is awkward to do without, you'll reach out for them. Or not if there is a simpler solution.
Don't get me wrong. This article was very helpful because now, when I eventually see auto&& ...x in a function declaration, I'm hopefully going to remember that the feature is called "parameter packs", and will find this article again with a search if I can't remember what it means.
But realistically, I'm not clever enough to write code that makes use of the various implementation specifics discussed here (stuff like "init-capture packs" that let you efficiently capture a parameter pack into a lambda, and dozens of other similar cases). Having a summary article that omits all that would be more readable for me.
I've had this same feeling about most C++ features lately like coroutines and concepts. Authors take great pains to explain how I might write a library that uses coroutines, but as an app developer I'm never going to do that — I'll be using somebody else's higher-level library because that's how it works in companies with these modern C++ codebases. OTOH, that also means it's hard to write generic documentation from the user point of view because it's often so tied to specific libraries.