I agree, ASSIGN would make more sense everywhere where variables are assigned. Easy change but also backwards incompatible so needs to be done in a major version.

Now that we use ASSIGN token type instead of VARIABLE, it would be a good idea to enhance the parsing model so that ForHeader.variables is renamed to ForHeader.assign and ExceptHeader.variable to ExceptHeader.assign. Old propertys should be preserved but be deprecated.

Need to also think should we change the running and results models the same way.

I've now locally done the parsing model change I mentioned above. I like the consistency with property names and token types. We also already used assign property with keyword calls and inline IF so there's even more consistency.

I've also started changing the running and result models to use assign instead of variables or variable. Also that change looks good both in general and for consistency reasons. Unfortunately it also makes this change even more backwards incompatible. I'll list those changes separately when everything is ready.

I now ought to have all models updated locally and will commit and push changes after I've gone through changes once more. I try to list all backwards incompatible changes and deprecations caused by this issue below:

• Token type of variables associated with FOR and EXCEPT has been changed from VARIABLE to ASSIGN. This was the original requests in this issue.
• Parsing model objects For, Try, ForHeader and ExceptHeader nowadays have values of the aforementioned tokens available via property assign. Earlier the property was variables with FOR and variable with TRY. Old propertys still exist but they are deprecated.
• Execution and result model objects related to FOR and EXCEPT now have assign attribute. The old variables and variable propertys are preserved but deprecated.
• Execution and result models objects related to FOR and EXCEPT accept assign, not variables or variable, when initialized.
• In output.xml possible EXCEPT assignment is now in attribute assign of the <branch> element when it earlier was in variable. FOR variables are still in <var> elements that also keyword calls use. Old output.xml files using the variable attribute are supported, but new output.xml files aren't compatible with previous Robot versions.
• JSON serialization of the running model (Support serializing executable suite into JSON #3902) now uses assign with FOR and EXCEPT variables instead of earlier variables and variable. Old format is still supported when when processing JSON, but new JSON outputs aren't compatible with previous Robot versions.

Hmm, we still use Token.VARIABLE with variables created in the Variables section and with the new VAR syntax (#3761). That's somewhat inconsistent, but changing the former would be hard because Token.VARIABLE is also the type of the Variable statement and the statement type not being used by the statement tokens would be somewhat odd and also complicate parsing a bit. Need to think about this.

After discussion on Slack involving also @Snooz82, we decided to revert the token type changes in RF 7.0. In addition to the inconsistency mentioned above, there are some other issues with token types. We won't have time to go through them all now, and making some changes now and more later would add more work for external tool developers. Better to do this properly in one go. I'll submit a separate issue about that to RF 8.0.

Notice that the model changes are preserved. They aren't backwards incompatible because the old propertys are preserved (but deprecated).