This bug is easy to reproduce. Create an object with an enum, create a microflow that changes the enum (commit without refresh) and show a form passing this object with a conditional visibility on this enum. The form will show the old state.
We've justed put some more time into the case as described by Ronald and it turns out this behavior is the same in 6.9.1 and even in 5.21.5.
So my initial assessment: this might be happening due to some changes done for Mendix 7 that were backported to / already included in 6.10.4 which means a refresh is now needed.
Was not correct because I based it on the assumption this behavior did change from 6.9.1 to 6.10.4.
Given the above I do not think this is a bug because:
1) The user has object "someEntity" with id "1" in his browser and sends it to the application server (=microflow).
2) The application server creates a copy of the "someEntity" with id "1" and changes one of the attributes.
3) The application tells the browser to go to page "X" and to show "someEntity" with id "1".
4) The browser checks to see if it already has "someEntity" with id "1" in cache. It has, so it will show that one.
5) Since there was no refresh in client triggered from the application server, the browser is still showing the old version.
Fix: add a refresh in client on the change of the entity.
You could argue we should always force a refresh in client on a show page -> parameter entity.
You could also argue the current implemnetation is preferred as changing it will take away control from the developer and break existing functionality for developers relying on the current implementation (there might be cases where you do not want to refresh the entity in the client, for example when changing attributes that are not shown in the client).
So to summarize:
Behavior as described by Ronald did not change from 6.9.1 to 6.10.4 and was already present in 5.21.5. So we do not consider this a bug, it could be considered a feature request. But there are valid reasons as to why the current implementation would be preferred.
If there is another case that does not fit in my description above (like perhaps the one of Nikel) I would suggest filing a separate ticket for that.
I encountered the same issue in a slightly different form. When retrieving an object from a datasource microflow, I need to force a feresh as part of the microflow. This results in the whole object state being described twice in the repsonse to the client, but solves the issue that client does not update otherwise. Seems like a clear bug to me.