Unless I misunderstand your question, you have have answered it yourself. :) Object A is changed in the first microflow, so naturally, the values would be different in the sub microflow? In the first microflow, you could make the changes to A and then don't commit or refresh. In the sub microflow, retrieve over database (old, saved changes) rather than association (most recent and unsaved changes) to get the data, and then commit at the end of the sub microflow.
Just a thought.
I presume the difference is caused by change actions that have not yet been committed to the database. In this case it is possible to have 2 objects with the same ID with different attribute values.
This occurs when you change an object without committing. When you then re retrieve the object (over database!) you get the same object but from the database and not from memory. If you want the object from memory (so with the changed attributes) you should use the retrieve over association action.
To debug this I would start with checking the attributes of A that have different value. Goto object A and search for microflows that changes that attribute. Because in my opinion the only reason that Object A differs is when something else has changed the object in the mean time.
You could also use an after commit action on the object with a breakpoint so you can check the data each time the object gets committed. When after these checks the object still has different values file a bug report. But my gut feeling is that somthing else is changing the object in between.
Regards,
Ronald
I have found that the cause was by a webservice that I called in an earlier stage. After calling the webserivce I change the attributes of the object, and the microflow continues with the logic of the changed object. When retrieving the object over association though, I get the object that was sent with the webservice. This seems like strange behaviour to me but at least I was able to come up with a workaround.