And, of course, you could be nit-picky about side effects. For example, a language might implement assignment such that the first time you assign a value, it allocates the memory and the second time it simply overwrites the memory. That's obviously not idempotent. However, you could make similar arguments for a lot of compiler optimisations: they can take an idempotent function and make it not idempotent when viewed from outside the context of the source code.
While there is some value in considering those issues, it's a bit self-defeating as well. You take a useful abstraction and throw it away. I think it makes sense to have conversations like: is this idempotent from the context of the source code? Running out of memory when you assign to a variable that's allocated on the stack is not something anyone normally prepares for (and if you do, then God help you ;-) ). The concept still provides value to the conversation, which is the reason for having words in the first place. You may prefer a different word, but if it's going to be used in every single case I would question the utility of the redefinition.
These two operations have different results:
1. A=5 2. A=6
vs
1. A=6 2. A=5
In such scenarios, whenever an operation is performed, the assignment operator is no longer binary. You also need to include the ordering information (e.g. randomly generated) in the transaction, such as:
ASSIGN(0, A, 6) ASSIGN(1, A, 5)
Then operations are performed in the order depending on the first value in the tuple.
As you can see, idempotency of assignment is only true if it's ordering value is the same.
The server is free to change the state of a resource at any time without informing the client.
What a compliant server cannot do is change the state of a resource as a result of receiving the GET request from the client.
Even a classic GET request on a REST api, is only idempotent if you ignore the fact that the data changes over time.
I guess what I'm saying is, outside of formal systems, I think it's all deduplication.