Ralf, 
thanks for the explanations!

Still I am not sure what the expected behaviour from users/admins of 
roundup is. Some thoughts:

There is some logic in the current behaviour in that a change
often depends on the values it was aware of.
So if two changes (or better change requests) are coming in, 
they have no chance to be aware of each other. 
So how to resolve this conflict?

There certainly are use cases where I would want both change requests 
to be serialized and thus resulting in a full history. These are the cases 
where the "old" values do not have to be known to do the change.
For the other behaviour I'll find it naturally that one is rejected as it could 
not have known the "old" values. Given that emails could be written well 
apart, but still come in at the same time, I also believe that the behaviour 
should be the same no matter when they arrive.

If a change-request comes in, we currently have no way to know
on which old values the decision for the change was made.  We could try 
to introduce a way and it would allow to decline a change if it was
not based on the latest value. Right now I cannot say if this is a real
use case or not. 

What I also don't like is that the behaviour is different for the backends.
In my view a roundup-based application should basically behave the same 
on all backends.

In anyway, we certainly have to describe 
the behaviour in the documentation.

Bernhard