After reading the above link I still feel that there’s a disconnect here. The approaches explored in the above paper discuss clearing the final state of sensitive storage, but do not address “under the hood” relocations of sensitive data such as occurs when the Rust runtime grows or shrinks a vec that contains sensitive data. Thus the storage that was once occupied by that data, but that is no longer so occupied at Drop, is never cleared.
The paper suggests a language enhancement to permit annotating selective data items as requiring guaranteed erasure on drop/relocation. Such an indication of programmer intent is probably the only means, long term, to address the issue in the presence of increasingly-sophisticated code optimization. It is also good programming practice: specify intent explicitly, rather than attempting some obscure kludge where the desired result is actually a side-effect.
If a programmer forgets to declare that specific data is „sensitive", that’s the programmer’s fault. If it is so declared, then the compiler can enforce storage being overwritten immediately prior to the item’s destruction or after its relocation, leaving leakage and various side-channel attacks as the primary remaining vulnerabilities.