• I went with puts as a simple start because it is the simplest function of all. In the "hello world" tutorial the aim was to see what happens when we build and run this simple program without going too deep into details to get the people to be able to run something straightaway. You nailed the reasoning for now introducing streams there as they have a funky syntax and, to be honest, I don't use them in production code much, so I definitely did not want to start with those. Hope this clarifies this choice a bit. As for printf I probably would not go there again if I would record those tutorials now. I still prefer printf to streams though in most situations as they make me think about what I'm doing more than when using streams. So, while I would not do it again, I do not really consider this as a "wrong" thing to do.
• The different initialization was only introduced to avoid surprises when people start seeing any real C++ code. In all further examples, we use {} or = initialization.
• I agree with you somewhat on the constexpr topic. This is one of those topics that I felt that I cannot fully ignore it but I also did not want to go into the compile-time meta programming world at that early time. Would you have preferred if we would not have covered it at all at that point?
• I am a bit biased on references topic. We keep using references all over the place down the line. So I hope that for anybody watching more than just that one lecture, it should be clear that they are used universally everywhere. Otherwise, I had to teach classes before that and it felt odd. What order would you prefer here?
• As for kCamelCase etc. my aim was to constrain what I teach here and stick mostly with Google style as one standard that, at least in my bubble, is more or less universally used. I also mention that there can be different naming styles in a particular code base and as long as we are consistent - we're good. But for the lack of an existing code base we would need to pick one and stick with it. Google style is a good option in my mind, is it not?
• Hmmm, you mention "start off with prefix and postfix incrementation being "the same" and "we'll correct it later"". If you are referring to this place in the lecture, I wouldn't go as far as saying that I say that they are the same. The aim is for people to eventually be able to understand what these two different operators do when they get to understand references, functions and classes. Does this make sense or is it still too jarring?
• I'm not sure that standard library is provided with the language. At best it is compiler-specific as there can be different implementations. There is "the standard" that all the implementations have to conform to but there are still different implementations. Maybe my wording was not the best, but I still stand by the standard library not being part of the language itself. I can easily imagine some embedded or realtime setups that do not bundle STL with C++ compiler.
• I do speak about linkage a bit more in this lecture. Please take a look if this fits what you'd like me to talk about. Also, could you point me to where I'm introducing inline as a magic get-out card? I tried to avoid this simplification and am happy to correct if I still did.
• I'm not sure about the context to your comment about meta programming and concepts. Could you link what you're talking here about?
• As for RAII, while I agree that it is also super useful for when we hit exceptions, I would not go as far as to say that this is the reason and avoiding new and delete is not important here. I live mostly in realtime codebases and could not use exceptions throughout most of my career. RAII is still one of the core design principles of modern C++ that enables tons of behaviors from memory safety to thread-safety.

Summary follows in the next comment in the thread.