As authors we need to understand that aspiring programmers have the whole web, where easy to read blogs and article surface on a daily basis. Paper books are more of an impulse buy than a self-education commitment. Books are too monotonous and incomplete to compete with the web.
That said, I will be honest and say that I will not buy this book. I will just Google for topics, read a book like Learn * the Hard Way  or take one of the Coursera courses  to get started. I would encourage you to find new ways to delivering study materials (through video for instance) than just writing a book -- which I personally think is a disruption waiting to happen.
On the other hand, if you succeed in writing a book like , then things are different -- you are explaining programming and not a language (syntax, features and caveats).
What I am suggesting is that a section on compiler warnings is just stamp collecting. The reader still needs to RTFM. Same with source control and development servers. At best these are items for an appendix or end notes. Don't drag the reader through context unless you are writing a textbook - and even then, don't.
I guess the tl;dr is that the table of contents looks longer than necessary for a book which has a thesis about design. Respect the fact that your readers will work out the implementation for themselves. Save "Use const wherever possible" for the supporting blog.
Edit away everything that is unnecessary, as I have not done with this comment. Do you really have something objectively important to say about namespaces, or are you just expressing an opinion based upon your preference? And even if you do have something important to say, about namespaces, is it something that a professional developer can integrate into their existing workflow without horrible disruption?
What is the MVB?
NOTE: I am not sure I would buy it, but I might read it!
I'm a C++ programmer with over 10 years, I buy software books, but I basically only go for well vetted books.
I dislike a chapter heading reading "Exception throwing destructors" even if that is a one page chapter with one big word "Don't." It also happens to be the type of thing I already expect a professional C++ programmer to know.
Actually, the only chapter I found interesting is #12 (MapReduce) and it doesn't really have much to do with reliable C++. But after reading up on this, I found that it gained little interest in boost , and its description in  is rather bland. Compare the description for N3554. So, instead, a book with only chapters like #12 but which touched on very useful, well-tested libraries would actually be more interesting. Not the normal libraries, the usual ones like boost in which professional programmers should already be adept, but some other ones that are real gems nonetheless. But all that is assuming that I would still be interested in writing C++ code.
However, I don't really see a future for C++ for most purposes, so "Scala for Profesional C++ Programmers" may be even more interesting.
You've got two sections, guidelines and design ideas. I would probably get the most value out of the design ideas section, as learning new patterns to do things well is always handy.
But the guidelines section you're going to have to be a lot more careful. Most C++ advice books are targeted at beginners for a good reason, everyone has an opinion about how to write C++ best and they are rarely well supported. I would expect advice intended to be taken seriously by professionals to come with specific real world examples of how it addressed a reliability problem in a largish project, not just an expert author's say-so.
If you could actually collect that, it would be incredibly useful. You could even give it a nice inflammatory title like "n C++ mistakes that have wrecked projects"
My gut tells me that the Cpp book market is mature. Clojure is a language where one could combine the literary tradition of Lisp with the sobriety of the Java shop.
For ch9, it's like a C++ version of the Goetz book... you should make the same point: people shouldn't write their own thread pools. Also make a point about ownership transfer when posting to a pool: just don't share any data.
Step 2: ???????????????????
Step 3: Profit $$$$$$$
like there aren't 100 Cpp books already available that would cover the topics in far more detail than this ever would.
The beginning of Part 1 looks more like a beginner programming book than a C++ book. They're important topics, but none of them are specific to C++, and they're not the reason I'm buying a C++ book.
The rest of Part 1 looks like a rehash of "Code Complete" and "Clean Code." There are already good books on those subjects, and I'm not seeing what this one adds. Might be interesting to the same people who don't know about SCM and compiler warnings, but I'm not in that demographic, and even they are probably better off in the long run going with other books.
Part 2 looks interesting, but not enough to buy the first half of the book along with it. There are other books on writing reliable multi-process/multi-threaded code (both in general and in C++), and my impression is they would go into more depth than a book that tries to be as broad as this one.
I should point out I was already predisposed to say "no" because my preference is to avoid books that tie themselves to a specific language unless I'm learning the language or the particular language has an unusual advantage for a particular thing (such as Erlang for reliable multi-processing). Unfortunately neither of those apply here, so I'd prefer the more general books on these topics.