Something really cool i think would be to have predefined object “states” (other potential names: “preset”, “keyframes”, “configurations”). Basically, you could open an object in a “layout editor” with only that object, and change the instance parameters like position, angle, variables, etc, and have a bullet list of all states (you can add any you want). Each state would store that configuration, and you could see and edit the configuration of your object for any state.
When placing an instance, you can set the state it is in at creation in the instances properties editor, but also change the configuration of a state for this instance.
Finally, in events, you would have an action to set an object to another one of it’s states, a condition to check the object state, and most interestingly an action from the tween behavior to tween all properties different from one state to the ones of the other.
This would be a very powerful feature that would simplify many things:
Animations
This can be used to make “keyframes” for animations with the IDE tools, making it easier to make complex animations. It could be a first step towards making a timeline, by adding keyframes that could be used on such a timeline.
A simple example for a simple animation would be a pause screen: you could have an object group of objects constituting a pause menu, maybe a play button, a black backdrop, and a “modal” sprite. We could then make for each a hidden and visible state: the backdrop has either half opacity on visible and 0 on hidden, and the sprites have scale 0% in the hidden state and a scale of 100% when visible.
Simply tweening from hidden to opened and back makes a smooth opening and closing animation that can easily be tweaked visually without entering all parameters in very long animations events in the events sheet 
Finite State Machines
This also simplifies state Machines a lot: we can use the states of an object as the states of the finite state machine. That allows to visualize different states, set for example a sprite’s animation for each state.
Assuming we can modify behavior properties on instances in the future, we could also set different parameters of behaviors depending on the state (for example smaller platformer jump height when in the crouching state).
This allows moving the declaration of different states of the FSM away from events, and to keep events for defining the transitions and logic bound to the current state.
If in the future we also add events sheets bound to an object (for the sake of organization and cleaner sharing of logic of global objects across scenes), we could also add events sheets bound to each state (for the sake of organization) that only run when an object is in a specific state, this would also get rid of the boilerplate code to check in which state the object currently is and run the appropriate events accordingly.
Additionally, this feature would change the way of thinking about objects in a away that might make FSMs easier to understand.
Improving IDE workflows
The engine makes some default decisions when placing instances, like the default layer or z layer. While those defaults are good most of the times, some games require some objects to always be on the same layer, z order, or have because if the asset creation workflow to have a different angle or scale than the default, etc.
By modifying the base state on the base object, all created instances will have those default overridden by the default state.
Another common thing might be to have elements that can have multiple default states, like checkboxes/toggle switches. This allows to have a cleaner way to set the default state per instance (rather than setting the animation/a variable on it).
