We should (but the C++ committee too often does not) distinguish between additional complexity to serve some particular purpose, and constant greenfield development done solely because it was easier to burn some more forest than deal with the mess left by the previous occupants when renovating. This latter practice is of course unsustainable.

It is also good to distinguish complexity which matters to the implementer (for C++ this may represent maybe three groups - LLVM, GNU and MS - all of which have committee members) versus that which matters to ordinary programmers.

The novice Rust programmer in 2022 sees only that arrays work as you would expect -- the apparent complexity is quite small. You can't grow or shrink them (use a Vec) but you can mutate them (if you asked for a mutable array), you can iterate over them like other containers, they have the affordances you'd expect from a slice type (e.g. you can sort them, and if they're sorted you can do binary searches, that sort of thing) and so on.

In fact arranging this was pretty complicated, const Generics are involved for example, which Rust 1.0 did not have. But this novice programmer needn't care why arrays work, they just do, it's very simple. Compare the C++ novice who will be told that only some array features work, and they're not a collection, and they also aren't really a slice, and the affordances you'd want are missing, the C++ novice must carry around a pretty complicated understanding, all in order to simplify implementation for a handful of people.

Rust also has a third distinction of complexity, where it matters whether the complexity is exposed in safe Rust. For C++ the pointer provenance problem affects everybody. Finally resolving this long-standing hole in the C++ standard would significantly increase complexity for the language, and every C++ programmer may be at risk from the consequences. In contrast, safe Rust programmers needn't even be aware that provenance is a thing, only the nomicon explains that of course pointers aren't really just addresses because only in unsafe is management of provenance your problem.

Const generics, what C++ calls non-type template parameters, is a recent and fundamental complexification of Rust. Libraries using them, as always and ever for all features and all libraries can be simple, but a person coding a library that would benefit from the feature is in no way insulated from it. Async/await, similarly. There is no end to those. They add complexity, but solve real problems. Novices can be shielded, but professionals cannot be, because the features are exactly those needed by the professionals.

C++ chooses to add wrinkles, upon wrinkles, upon yet more wrinkles so as to produce a fractal of complexity that serves nobody, not novices, not professionals, not even the implementers benefit in the end. In the short term it was an administrative convenience I suppose, but it can hardly have been difficult to foresee the consequences.