I'll die a happy man if Spriter can have a dedicated interface within C2, less plug-in, more bolt-on. Thoughts 
lucid?.
Definitely. There's a few requests I have for the plugin system (and it seems from the blog post Ashley is thinking in this direction already). I'll go ahead and respond to thread topic as well, with general requests for c3.
I don't have time at the moment to read back through the thread so I apologize if I'm rehashing anything.
capx based edit-time ui creation
I would like for the edit-time ui programming to be a alot more like runtime programming and eventing. You could include in the plugin directory something like a small limited capx that serves as the ui for your plugin when double clicked or hovered or whatever you set in the edittime. For instance, you could make a capx that has drag and droppable sprites, dials, combobox boxes, etc. There could be an editor ui plugin or system actions that let you set values that can be passed to the edittime of the plugin. Same thing for plugin input parameters. It'd be cool to be able to create an interactive ui for ACE parameters using a capx. You could make it so users could input your color parameters with a color picker, and some numeric values with sliders, dials, spinboxes, etc, instead of typing.
But the real power would come from being able to combine several parameters within a single control. You could make a mini-capx that creates a visual speed (easing) curve editor that sets each control point and curve parameter, or see a preview of an animation at the time you're sliding to between 0 and animation length, or anything else you could create in C3 for game use, would be useable in the parameter input ui. You could make particles show an animated preview using the parameters you're setting with sliders, or a scrolling background showing you the speed that you're setting with an 8 direction behavior.
To avoid plugin UIs becoming too huge and bogging down the editor, there could be a simple restriction that you can only use a shared set of useful ui images for sprites, like triangles, dots, and all ui element type plugins, any images from the current project, and maybe a super small allowance for custom ui images. Maybe it could have a file-size or event limit as well, so they can either be loaded quickly or stored in ram. I believe Ashley mentioned in the blog the idea of being able to make plugins out of events, so if something like this was implemented, it'd make sense to give these same abilities to event sheet based plugins.
plugin access to create lists like the animation name or function name list
This might already be possible, but it would be good to be able to add to a combo_box or autocompletion list at edit-time, so for the Spriter plugin for instance, you'd be able to choose animations, entities, character maps, etc from a drop-down list.
additional variable types
Some of this could be made into plugins and behaviors for C2, but it would be a lot cleaner if it were built in. I'd like there to be dictionaries and arrays as regular variable types for object private variables and global variables. I'd also like to see objects as variable types, and any combination of the above, like a dictionary of arrays of objects as a private variable to another object.
new function object and variable objects
I'd like a function object that can take objects as parameters as well, and a special 'variable object' that you use a proxy to objects used as parameters or variable objects called into it. They would have all the commands that are common to many objects like create, destroy, set width, height, scale, angle, x, y, etc. You could then use this object as a proxy for the object using all the associated actions, conditions, and expressions are. The function object (and may even the global and private object variables) could also specify a specific object type, so you could make a parameter specifically for "sprite" or "particle" types, and then only those would be valid as parameters. In these situations you would get a variable object of that specific type and have access to all of it's functions even though you weren't sure which specific 'sprite' or 'particle' object type you were dealing with. Variable objects could also have set private variable by name, and if the object had a variable by that name it would be set.
behavior universal data sharing
For behaviors, I think it would be extremely useful if there was a concept of universal data sharing. Let's take the 8 direction behavior, the platform behavior, and the physics behavior, which all have the action setVelocityX, and an expression called velocityX (or something similar). Of course, any plugin could ignore the universal settings and keep their own local copies if needed, but each plugin would have access to a setGlobalVelocityX (always pixels per second), and getGlobalVelocityX, and others for rotation speed, etc. Now if you move a sprite with 8 direction behavior, physics behavior knows it's moving at that speed, and behaves accordingly, and vice versa. Or if you want to switch from platform behavior to 8 behavior on a certain event, when you switch over control it will automatically set it's velocity. As an alternative to the functions like setVelocityX, etc, you could just set the behavior to participate or ignore each value, and it would automatically make the velocity calls by checking the x, y, angle, etc, each tick and using those to determine velocity. I also like the idea of being able to set whether to update those values when you use common world object commands like setX or setAngle, so if you manually control your character with commands like setX or angle, the object will have appropriate momentum with any plugins. This universal data sharing for behaviors would also work well with the variable object concept, as you could also have a universal set of commands that could do something similar to all behaviors.
more granular SOL access and object picking
I'd also like to see some additional picking features, like splitting up a single object type into multiple selections, that you could call by a custom tag or index. One example usage would be having an array of objects, all with physics behavior and you want to make a rope bridge. You could just run a loop and say plank[loopindex] create hinge to plank[loopindex+1]. Or if you had a function with the object parameters "attacker" and "defender", then you could access two of the new Variable type object and be able to easily refer to one or the other in any actions, conditions, and parameters. For example, you could say : Set VarObject[attacker] position to VarObject[defender].x, VarObject[defender].y