(1) It is not designed to find more memory errors than said X tool. It is designed to find complete runtime memory errors that can cause security concerns, more specifically, like remote code execution and information leakage (like heartbleed) with very high probability. The probability is determined statically by source code pattern instead of the permutation of malicious input. In theory, you can intentionally write code that cause the runtime checking fail to catch a runtime error.

The minimal code example: Try to iterate the CLI argument of this code snippet https://stensal.com/a/demo_reporting, Valgrind and Asan will not report the overrun when the input is larger than certain numbers.

(2) It currently supports C++14. It will be upgraded in the future releases to support C++17. It is based on the great LLVM/Clang compiler framework.

(3) CI server needs a group license with discount. If all individual developer already has license, there is no need for extra license.

(4) Slowdown can be optimized based on user requirements.

I think (1) is the wrong question to ask, because none of these tools are suitable for usage in a production deployment, so you will only find those bugs with them that can be triggered with your test suite, which is necessarily incomplete.

A better question is, is this new tool intended to be used in production deployments, and what, if any, new attack surface does it introduce?

As you have rightly pointed out the intended use case. I want to add more constraints to it. It's intended to be used in production deployments that are security critical, constant applying security patches is not an optimal solution, and slowdown is bearable.

It will introduce denial of service attack. QMS executables can operate in two modes: warning mode and crash mode. Both will reduce the level of service, but neither will allow memory accession violations to happen.

Edit: added more constraints to the suitable production deployments.