That’s right. When a command arrives on the OH event bus, it triggers any rules looking for ‘received command’. It triggers any bindings that might pass the command to external devices. It also triggers the autoupdate feature that generates an update of the Item’s state (unless inhibited). The race is on … what happens first is indeterminate, but autoupdate effect is always a finite time later.
So, a rule triggered by received command that examines the Item.state may get state from before or after autoupdate changes it. It may change during the rule execution.
We’ve all fallen into this pitfall. You can deal with it by using the receivedCommand within the rule, or you can trigger the rule instead from Item changed or Item updated, if you need the update to actually take place.
Passing receivedCommand to a lambda function should ‘capture’ its value during that call.
I find it helpful to think of autoupdate as a psuedo-binding. Like other bindings, it listens for commands and responds by putting an update on the event bus for OH to process - eventually.