> kinda of like the journey of the function plugin, it was a separate plugin for a long time until it became a first class citizen of then engine.
I'd really want to avoid going through that again. Replacing a major feature with a different and not entirely compatible one is a painful transition to go through for both us and many users. It also leaves us supporting both indefinitely, as there are always too many remaining projects using the old feature to justify removing it. It's much better to get it right first time wherever possible. The only reason we didn't with functions was it was designed in a hurry in the early years of C2 with many shortcuts deliberately taken, and the replacement was so much better (and so many people were asking for improvements) that it justified all the pain and awkwardness of going through a replacement.
We all know this proposal about the global sprite with instance vars acting as an enum (by all I mean, people working with Construct for quite some time now) but as you mentioned it is a workaround. It works very fine, and sometimes is enough, but how about new user experience? This isn't something new users can get that easily, and when I first started Rhythmy over two years ago now (as an example) I had no idea this could be done and just assumed that enums/lists just weren't a thing (and in some way, they're not as this is a workaround
if the work around is the preferred choice, it should be its own object type (not associated with sprite, which has has rendering/world properties etc)
If my proposal would require too much work, maybe this could be a solution, because it makes no sense to make an empty global "sprite" to make a static enum? (and for new user experience, even less)
But maybe looking forward to an official solution like this, that won't require a massive rewrite of the engine as you mentioned, because that definitely won't be possible with the current ressources you guys have, maybe this can be a solution that won't require an insane amount of work, and improve overall workflow.
And that way, you won't be "erasing" or forcing replacement for people that were using the old workaround, because as it's a workaround, it would still be possible, but you're giving the opportunity to have it supported more "officially"