If you've not written C++ code before, it can take a while to catch up with the latest developments in C++23. Start with C, and learn these, in approximately the specified order:
1. lvalue references.
2. Constructors, destructors, and inheritance.
3. Annotations such as const and noexcept on members.
4. Simple type templates, and value templates.
5. constexpr, std::move, and rvalue references.
6. Type traits and std::enable_if.
Once you learn the core language features, learning the various data structures/algorithms in `std` should just be a matter of looking them up in cppreference, and using them over and over again.
That said, I like your ordering too.
The other confounding factor is that I have also written a lot of Java code (both during the development of the language and afterward for my column in Javaworld) which I really enjoyed, but it too "fixes" some things which James disliked about C++ (and as a long time C programmer I understood quite well).
As a learning experience, this journey has been confounding, enlightening, and painful in equal measures :-)
If you find yourself reaching for std::shared_ptr and virtual functions more often than once in a blue moon, you are suffering from Java Disease, and are writing bad code.
Anything that seems to be something Java "fixed" is a thing they failed to understand. You will have to unlearn those, along with myriad bad C habits, many of which you don't know you have. It takes sharp observation to catch them.
As someone with north of 15 programming languages that I consider myself "fluent" in, albeit some latency involved in ones I've not used for a while, I always look for the idiomatic expression of computation. It is the difference between "writing FORTRAN in <x>, and writing an algorithm in <x>."
One of main the reasons I posted the question is that I found that design patterns I expected to be there, were not there, or were not idiomatic, and for whatever reason I am reasonably good at figuring out when something is "not quite right."
That said, I think it is unfair to characterize the choices of any language designer as either ignorant or wrong. As someone who participated in the design of Java I can assure you that the team "understood" why C++ did what it did. During that development, if there was any confusion, Guy Steele, whose office was three down from mine, would eloquently explain it so that everyone could understand it. That is not to say there weren't different opinions about "better" ways and "worse" ways to do things, Bill Joy was never a big fan of the Java choices and often took the opposing view across from Gosling. The language that Bill was designing was called 'Self' and it embodied his design choices, just as Java embodied Jame's design choices.
Me, as a systems guy, could really care less if Boolean was a first class type or just a uint1. I just want to write code that works.
What was much worse was copying in wholesale the C crap that C++ had been obliged to adopt to maintain backward compatibility with C, when Java faced no such constraint.
Have you considered self ? https://selflanguage.org/
Java was released in March of 1995, about 1/3 of the original Java group left after the 1.0 release (not in a small part because of Sun's attitude). I made the mistake when I went to work at Google of disparaging Self (which Urs Hoezle had worked on and was my boss's boss, oops!) But much of the original Java team had ended up there so it was kind of a fun to catch up.
So when you visited Craig at Stanford did you get along with him?
You may be reviled by that design decision, and the ramifications thereof, but I'd put my money on Guy Steele having a sharp grasp of the feature, the alternative design decisions, and the ramifications of most possibilities. If I were designing a language, and could pick any of a handful of people to help with the design, Guy would be near the top of the list, if nothing more that for his ability to explain things clearly and succinctly.
I cannot account for Java having retained so many misfeatures of C despite having no backward-compatibility constraint, other than that nobody was paying any attention.
Which is hilarious coming from C++ people who blindingly obviously didn't understand the features of Smalltalk.
But there are also tons of classes in Qt that are not QObject, esp. all the value classes like QList or QPoint or QString.
If anything, the biggest sin of QObject might be its name. If it had been named QActor or something like that, people wouldn't mind that much.
QObject is not Qt's greatest sin. That would be its lower-case macros: "slots" etc. There can be no excuse for that. Even C coders knew better, even back then.
constexpr seems to try and step in, but there still is a large codebase around which is hard to maintain and extend. IMHO D and zig show that it can be better to have compile- and runtime-syntax much closer together.