FWIW I think this is actually a pretty complex feature to implement which will involve a lot of work, and meanwhile there are already what I'd consider to be decent workarounds. If we go as far as "first class enums" where it's added as a general data type, some of the complications I can foresee are:
- Creating some kind of enum editor which creates a new enum type
- Creating some kind of convenient place to store enums in a project (would it be part of the Project Bar for example?)
- Much of the engine assumes types are a fixed list of "number" and "string" (and maybe "boolean" in some places too) - so a lot of code across the editor and engine would need upgrading to manage a variable list of types that depends on the particular project at hand
- People will certainly want to convert both from enum to value (e.g. enum to string) and value to enum (e.g. string to enum) and use expressions, otherwise it's worse than the workarounds - but then how does that look? There would need to be more expression features to handle this, and possibly more UI upgrades to the editor to handle this when entering parameters and such
- As with most event sheet accessible features, there will need to be ways to add, edit, delete, replace and refactor enums - e.g. suppose you want to replace enum1 with enum2, how does that work? How do you make sure events stay valid when these kinds of references change?
Meanwhile what I'd recommend for now is adding an object with a bunch of instance variables. For example if you add a sprite called "ColorEnum" with instance variables RED, BLUE and GREEN (corresponding to the strings "red", "blue" and "green"), you can do things like call a function passing ColorEnum.GREEN. They can be extended at any time, the values can be edited easily, renaming already automatically updates all references in the event sheet, you can still use expressions, you can use the existing "replace object" mechanism to swap it for something else, and there's no need for all the time-consuming design, implementation, user interface updates, engine upgrades, on-going maintenance, and general edge-case problem solving associated with a significant new feature.
So I have to ask, compared to that workaround, is it really worth it? I'd argue the opportunity cost is too high, and with our limited development resources we'd be better off working on something else, or perhaps adding minor features to smooth the workflow of the workaround case (e.g. perhaps by adding constant instance variables).