And there I haven't even given every C++11 feature a spin yet.

IMHO, you missed the best "new" feature in that list:
- Binary literals (yay, finally!)

Good to hear it was finally locked down, the changes to lambdas and the slight corrections to auto to handle them are useful.

As for C++17, work on it started when they started cementing what would not be in C++14, so it's already got about 3 years of work on it.

As it is a major version, there are quite a few big changes in the works.

More real-world concurrency and real-world parallelism, more networking, more real-world file systems, and language-supported reflection and "modules" are all under discussion. Just like before, most of the boost library is under consideration.

There might be an addition of larger bit types, although C++11's growth to 64-bit caused quite a lot of headaches, and the pre-C++98 transition to 32-bit was also painful for a lot of businesses. It would be cool to have some of the 128-bit and 256-bit data types available without platform-specific extensions.

That said, I think modifications to the language core are detrimental in the long run.

C++ has aged well, but most of that has been by sticking with the original minimalist roots. Additions and modifications to the language core push the language outside those minimalist roots. There are few features left in the imperative programming world that cannot be implemented in the language.

Some of the newer features are just syntactic sugar for things that could already be done, and I tend to disagree with those. I still think the range-based loops were unnecessary. The constexpr system just complicates what was simple and could already be done by leaning on the preprocessor. Others are frustrating in shortsightedness. The 'final' keyword is already a frustration for me, as I frequently write automated tests and system interoperations code so the inability to derive from a class to build a necessary adapter is quite frustrating; just because the programmer writing it is so unimaginative that he cannot fathom a case for extension does not mean no case will ever exist.

I would much rather they focus on standard library growth rather than modifications to the core language.

Any hope/wish/desire for the next standard?

Compile time reflections (and being able to process them)

I still think the range-based loops were unnecessary.

Can you elaborate more? Personally I feel it is alot more readable.

I still think the range-based loops were unnecessary.

Can you elaborate more? Personally I feel it is alot more readable.

It does not add anything new.

Many of the language changes added something that wasn't there before. Type deduction with auto was not there and there was no equivalent, it was added to support lambdas that have no expressible type. Lambdas were added and there really wasn't a good way to do it without them, there were libraries that did something very similar but they relied on tricks rather than being something natively handled everywhere. Addition of 64 bit types standardized something that was only partially developed as an extension on various platforms, each with their own different 64 bit name. These features added something new to the core of the language, made it something better than it was before.

Range based loops, however, added nothing. The old method was still there, and it is still there. The result is that instead of the traditional 'minimalist' approach, there is duplication. It did not enable any new thing. It did not add a feature. It did not do something that could not be trivially done before. It obscures details, adds an additional interface, but doesn't add any functionality. It is syntactic sugar, it is language bloat.

Glad to see C++14 finalized. I've already been making use of it as I tend to use GCC and increasingly Clang/LLVM.

Concepts are nice, but what I think C++ desperately needs is modules, and I don't think it can wait till C++17. We need modules yesterday. Besides that, I personally would like to see a standardized ABI for C++, as purposed by N4028, as that is something which I personally think is important.

It is syntactic sugar, it is language bloat.

It can make code shorter and easier to read. C++ is already extremely large and complicated, removing the "bloat" of range-based for loops would not improve the situation in any noticeable way.