I think we're approaching a point where we need to change the way we fundamentally conceptualize and define the behaviour of imperative programming languages.

Right now, most languages come with specific behaviour guarantees that are all effectively inherited from what made sense for ASM and the underlying behaviour of the computer's processor architecture, or at least what it was many decades ago. Some of these guarantees are useful today in certain circumstances, but many of them are actually not that useful anymore, but instead create non-obvious omni-present limitations for today's optimizing compilers, which we are increasingly reliant on and increasingly less likely to understand or control.

This is, in fact, surely the main source of refactors affecting generated code significantly. Whilst the refactor logically means exactly the same thing to the programmer, there can be a subtle difference in the exact definition of behaviour due to rules that shouldn't affect the logical behaviour, but in fact do restrict the compiler from performing certain optimizations.

The most fundamental concept is that code executes "line-by-line", or at least that execution is a physical reality, and its order is well-defined by the program. In fact, optimizing compilers have almost total freedom (and do) move execution order significantly. It is only limited by certain realities, e.g. that it's extremely difficult to prove that function calls can be called in a different order than what the program has defined.

I reckon that we need to move to a model where a well-defined order of execution is no longer an implied rule, and instead the programmer should be specific about when they need things to happen in a specific order. In fact, it's arguable that we should move away from the concept of tying code execution to processes or threads entirely. Obviously in a systems language it is still useful, but in most general programming usage it almost certainly isn't, and durable, asynchronous programming should probably become the norm, even for local tasks.

Non-C-like languages have already explored this territory, but now given just how complex compiler optimizers have become, it's becoming less clear that there is an advantage to having your conceptual model tied so closely to supposedly physical guarantees, given that your compiler basically rewrites what you write entirely.