Note that these are actually two different kinds of changes. (2) and (3) have the potential to give the program defined behaviour if it otherwise would have had undefined behaviour. On the other hand, in (1) I assume that you do not actually want to change the types for the purpose of semantic analysis (e.g., if you call a method on the object, you wouldn't want it to implicitly call the volatile-qualified overload) and you just want to disable certain optimizations. In that case, you do not need the standard, you just need to convince your compiler vendor to add an attribute that you could slap on the function in order to tell the compiler to disable those optimizations.

As for (2) and (3), I personally think that there is value in providing a way to opt out of certain forms of UB that have no purpose other than to let the optimizer make extra assumptions, but it is not clear whether the idea of controlling it on a per-function basis is coherent. GCC has -fno-strict-aliasing, which you can control only per translation, not per function; perhaps that is good enough already? If I were you, I would talk to the GCC folks and find out more about how that flag works, and to what extent it's possible to link together two different TUs where one of them was translated with the flag and the other was not, and other important details like that, and whether they see any obvious specification issues with trying to standardize such a flag (perhaps in the form of a new type of declaration that must occur at the beginning of a translation unit before any declarations of objects, functions, or classes).