Re-executing command results in active `Save` button

I have this (simplified) model in which I use an interface for creating pdf-documents:

'Document available': stategroup (
   'No' {
      'Create document': command { } //*[1]*
         => update ^ .'Document available' = 
            ensure 'Being created' ( )
   }
   'Being created' {  //nodes with this state are processed through interface
      'Creating document': command @hidden {  //command is executed by interface to provide file
         'Document': file
      } => update ^ .'Document available' = 
         ensure 'Yes' (
            'Document' = @ .'Document'
            'Document mailed' = ensure 'No' ( )
         )
   }
   'Yes' {
      'Document': file
      'Recreate document': command { } //*[2]*
         => update ^ .'Document available' = 
            create 'Being created' ( )
      'Document mailed': stategroup (
         'No' { ... }
         'Mailing' { ... }
         'Yes' { }
      )
   }
)

If I execute the command at [1], the pdf is being created through interface and after creation the stategroup Document available ends in state Yes and Document mailed in state No, as expected. Save button is not active, all changes are saved automatically.
Then if I execute the command at [2], the interface performs its task, stategroup Document available ends up in state ‘Yes’ and Document mailed in state No, but Save button is active, because the change in this last stategroup is not saved automatically. The question is: Why? Both commands follow the same process.

This is annoying, because changing states by execution of commands in following stategroup Document mailed are also not updated, unless user first hits the Save button.

To maybe answer my own question: I used create at [2] and changed it into ensure.

'Yes' {
      'Document': file
      'Recreate document': command { } //*[2]*
         => update ^ .'Document available' = 
            ensure 'Being created' ( )  //<-- changed `create` into `ensure`
      'Document mailed': stategroup (
         'No' { ... }
         'Mailing' { ... }
         'Yes' { }
      )
   }

Although I don’t understand why this should influence the execution of the pdf-creation and follow up changing of state, I will test this.

Unfortunately no, this didn’t solve the problem (as actually expected).

Thank you for the post. This is a client bug and will be solved in the next client release.

Thanks for the quick response. Indeed, problem solved.