Regarding sprites. There are advantages for both suggestions I can agree with. From personal experience I found the method in the 'old' Phoenix insufficient. I quickly resorted to my own version of a 'spriteengine' where I had more control over animations vs object states, as well as a different way of loading textures for game objects.

What I'm saying is, your implementation will probably work great for most. But no matter how many extra's you'll add to it, there will always be someone who thinks it's missing something they need.

Seeing how I eventually wrote my own sprite classes and even added tools to support those, I would now rather have a sprite object with separate texture objects. Meaning every sprite still has a draw function, but the texture object defines how it gets drawn. Hmmm, I think that is even different from what you are suggesting right now

Regarding your concerns about option x or y being harder for beginners. Honestly I think you shouldn't care about that a whole lot. Give them a few tutorials to read over and they'll pick up soon enough. You should integrate that what is best for the majority of users (I doubt they are beginners) and whats the best solution for your engine.

# Parent->Child relationship with relative transformations
That's cool, so we can use something like a particle trail on a spaceship.

# Plugins instead of inheritance.
I'm not yet convinced yet about the advantages of plugins. Inheritance is just too cool

# Sprite properties
How does this work exactly? Are these fixed properties for a sprite object?

# Sprite tags
Could be good. But like you said, too vague yet.

# Sprite classes
very interesting, especially the triggersprite!

As always, looking very much forward to the next update. How long do think for a more final version?