I would consider the sprite a game entity. I don't see why you want to store a big array of images and rectangles and control them by using other objects. Both the behaviour and appearance should IMHO be merged into the same object.
Moreover, the programmer can always decide to let one sprite "own" a few others. The owned sprites don't have alot of functionality and just listen to their owner. This can be usefull for e.g a spaceship with turrents. You can ignore the update-procedure, disable collision checking and such, and expose the internals of a sprite to make it behave as a simple controllable image.

If we write a editor for sprites you want to create a sprite with the transformation tree (adding visible turrets, invisible missile ports etc). Okey all fine, but if we decide on "i want a fleet" how should this be handled?
You could let the spacehip sprite create a few turret subsprites in it's own constructor and control them as if the are a single entity.

I have one idea that involves having the good old Sprite class with position and state and then just have a Clone function that does a deep clone on the sprite. That would work in a way that you have two sprite lists in the game, one list for Sprite "prototypes" witch are the sprites you create in the external editor. Then you just clone the prototype sprite and add it to the game world. Any thoughts on this idea or any better ones? I'm all ears!
You could add a virtual clone method that can be overridden by any child-classes. Each sprite-class can define it's own cloning behaviour, which should work flawlessly with any editor.

However theres some limitations when using both the old position values and the transformation matrix. If you modify the transformation matrix manually (witch could be useful sometimes) the values in the Position and Rotation values wont be updated.

The only way around this would be to remove the Position and rotation properties and replace them with functions like SetPosition, Translate, Rotate that modifies the transformation matrix manually. Returning the position from the translation matrix is no biggie so a GetPosition will be there. Rotation is a different issue and cant be extracted without arctan.

However using X and Y is alot easier for the beginner so i'm somewhat splitted there.
There are ways to decompose a matrix but they are expensive. A thing you could do here, is adding a virtual "ComposeMatrix" routine. This routine takes the translation, rotation, and scaling data and returns a matrix. If the user want's to do some special effects (skewing etc...), he can do it by overriding this routine, and possible adding some parameters as class-fields. Then there will be no need to modify the matrix from outside AFAIK, thus all data will remain synced.

Parent->Child relationship with relative transformations
Each entity will have a list of children, where the parent position/rotation/scale/color will be inherited by the children. This means that a tanks turret automatically will rotate when the tank body does.
That would be great, allthough i think that properties like color should not always be inherited. I'd give the programmer a way to prevent the parent from setting the child's color.

Some basic rectangle<->rectangle version would be doable.
This would be great. I'd add a "TestCollision()" routine to the sprite, on top of this rectangle check. The programmer can override this method and add his own collision-checking code. The DelphiX sprite-engine works the same.

Good luck with it.