Earlier quoted context omitted.
I didn't say anything about consumers caring whether a program was written in C++ or Rust, and I don't think consumers care about that. I talked about whether the product is full of memory unsafety or not. Where that is a relevant aspect of your product, Rust is far, far more productive--it's more or less impossible to produce a large C++ program without exploitable memory unsafety bugs, while it's fairly tractable i…
There is indeed a flat productivity metric. But of course, a programming language being a tool, its impact on productivity varies from product to product. I think my previous comment stands: Do you need fewer people to develop and maintain the product? That applies to every situation.
My claim is that a similar phenomenon applies for C++ and security, regardless of whether Rust is otherwise more productive: no matter how many people you add to a large C++ project, you are not going to come close to the level of assurance on security properties that you get from a Rust program of the same size (your only real hope is formal verification, which for verifying code in just about any language is multiple times less productive than writing the same code without verification). For these cases, asking which is more productive is pointless--C++ cannot deliver the expected product. However, if this is not the case for your project, I believe Rust's productivity benefits are more modest and are probably outweighed by things like team experience and available tooling.
I think I'm being pretty clear here about what I mean and why your question does have a single answer that applies in all situations.