my take looking at languages beyond C++ is a very different one

you want a well working general solution which works well (most of the time for most of the "generic code" (i.e. good defaults for the default use-case).

and then add escape hatches for micro-optimizations, micro-control etc.

C++ on the other hand was deeply rooted designed with micro optimizations and micro control first.

"Generic solutions" where then tried to be added on top, but not by changing a badly working abstraction/design but by adding more abstraction layers and complexity on top. And with a high requirements for back/forward compatibility, not just with the language but ton of different tooling. That this isn't playing out well is kinda not really surprising IMHO. I mean adding more abstraction layers instead of fixing existing abstraction layers rarely plays out well (1) especially if the things you add are pretty leaky abstractions.

-----

(1): In context of them archiving overall the same goal with just different details and no clear boundaries. Layering very different kind of layers is normal and does make sense in a lot of situations. Just what C++ does is like layering "a generic system programming language" (modern C++) on top of "a generic system programming language" (old C++) without clear boundaries.

C++ does have reasonable defaults. You never have to worry about move if you are using standard containers or unique_ptr.

But eventually those escape hatches come bite you and you need to worry about.

Complexity is inherent to the system. Wrapping it in a nice interface doesn’t make it go away.

—-

The problem I see is move semantics are a real thing in programming languages where types can own resources.

Most languages just choose not to handle them well or limit their feature set. For example swift tries to use copy on write to avoid it

So eventually feature creep happens and you get borrowing/move.