Thanks for reporting, I will look into it.

Independent of this, I would suggest to give rather specific names to states and make sure that states are indeed different in the sense that they are more than just two different hardcoded parametrizations of the same functionality. But of course, the issue you reported needs to be fixed.

This problem should be fixed now by the above referenced commit.

In short:

• Duplicate state class names are now correctly handled within the app.
• For generated code, duplicate state classes are imported with according aliases. This enables to correctly load the respective state class when loading a behavior in the app.
• There is a new entry in the settings to do the above explicitly for all state classes even if unique.