The basic operation required to construct functional graphics in Inkscape is symbol swapping. Swapping symbols allows you to use all the drawing features to create 'source' objects, and also create a 'destination' affine transformation. Whichever symbol you swap in inherits the clone's transformation.

The dice are very good examples - I create 6 dice group in which the faces are seperate clones. Then I update the xlink:href for each face to link the right one in. That is the only way to ensure that the faces are put into exactly the right positions.

1. I know it's a known problem. I submitted a bug report three weeks ago.

2. Sorry, that was very terse of me. Transformations are split between the group element and its children depending on when you grouped it and what you've done to it since; this is about the worst possible situation for scripting. What is most needed is an 'insertion point', with the group's children specified relative to this. But an alternative would push the transformation into the group, multiplying the group's transformation with the children's transformation. 'Invariant' because then the transformation would be be described in one invariant way, not split between the group and its children in an unknown way.

3. No, that will update all the clones. I don't want to do that. I just want to swap the symbol being linked to, for some of the clones. This, as I say, is the one operation that I find absolutely indispensible, but I can't do it on a selection of clones. I have to do it one at a time. This is annoying when I have to do it for a small number of clones; when it's thousands it's unthinkable.

4. Yes. That's what I currently do. Strangely, Flash lets you group one element even though it's not a useful operation in Flash (I found that out by accident on Friday).

5. Yes, I had read that on the wiki. Well, I look forward to it.

6. It breaks any clones linking to it. They should be automatically updated. Also it shouldn't require a 'Set' button because the UI paradigm throughout the program is for instant apply. Same goes for attribute assignment in the XML editor actually.

7. IDs are for programmer consumption. Labels are meaningless to programmers working with the DOM.

8. In view of the fact that programmers have to work with IDs, labels get in the way:

* They are pre-filled when they might as well be left blank.
* You have to set both ID and label manually - if you make the ID meaningful the label will still be junk unless you retype that too.
* They have a # in them. Don't understand why, if they are for user consumption.

1. Yes, it's a known problem, which will be fixed one day.

2. What do you mean by "making symbols more invariant"?

3. I don't think relinking a common enough operation to give it UI of its own. You can just clone a group, and then it's easy to delete old object from the group or add new ones into the group without ungrouping it, so all its clones update accordingly.

4. You can always group it with a temporary object and then delete that object from the group.

5. Support for is eventually planned.

6. The Object Properties dialog with its ID box looks easy enough to me.

7. Yes, using the original's ID as part of a clone ID is a good idea. Otherwise, of course IDs are "meaningless" - they are created automatically and not intended for user consumption, in general.

8. Labels are as "meaningless" as you set them. Their advantage is that unlike IDs they need not be unique and can contain any characters. This makes them useful for annotating objects if you need that. What do you require from them?