What do you mean by "temporal ones will be lower than 70%"? Are you suggesting --- referring to the article's cite --- that subcomponent ports to Rust reduce spatial vulnerabilities more than temporal ones? If so, why do you believe that?
I would expect more of the opposite for languages offering easy to enable bound checks. Only observing the general trend for when bound checks are available (and used) would be helpful information.
Temporal ones will remain tricky to debug until at least static + dynamic analysis via scheduling in kernel, hypervisor/simulation and/or run-time will become common-place. Probably even longer, because analysis is cumbersome for bigger programs without Seperation Logic (like Rust has).
If you're talking about the impact of replacing a subcomponent in a larger C/C++ codebase with a memory safe language and saying you'd expect that to make less of an impact on the temporal memory safety issues latent in the remaining C/C++ code, I guess I get that.
If you're saying that you think memory safe languages are less successful at dealing with their own temporal memory safety concerns than spatial memory safety concerns, that doesn't make sense to me and I would push back on it.
I do agree with point 1 and with most of point 2 besides some more arcane things like intentionally racy memory access and some write-cache eviction instruction not being properly modeled (in for example Rust).
