I've playing a little with Copy/Paste features. The basic support is quite nice and ingenuous. Some issues/observations:

1. The tutorial seems to assume that one will do just a cloning of the pictogram but not of the Business object. It should be clear that this is not necesary (I'm not even sure it's typical), one could also want to clone the business object.

2. The copy/paste inner working does quite dark magic (for me, at least) to place an EObject in the SWT clipboard, using the URIs of the EObjects (I would have expected something simpler, more like an serialization/deserialization, but I don't kwnow anything about SWT clipboard, and little about EMF).
This has some hidden implicancies: one must not copied pre-cloned detached objects, for example. Further, perhaps the tutorial (or the javaDocs) should mention that the canXXXX() methods in the Features should be as light as possible, in particular the canPaste() method is called a lot.

3. Because of that dark magic (I guess) the type of the content placed in the clipboard seems to confuse the rest of the workbench. For example, if I copy a graphical element (in the tutorial) and go to the Project Explorer, the "paste" menu is enabled - this is slightly incorrect, compare with what happens when one copies some text in a text editor.

4. For simplicity, the tutorial places the paste objects at the origin. I tried the more typical behaviour, placing the objects at some fixed offset from the original elements. It basically worked, but it revealed a little issue: if several objects were involved, only one of the new objects is selected after the paste. This is atypical and frustrating, because one frequently wants to move together the set of cloned objects.
Should I enter a bug?

BTW: Is there some programmatic way of marking some pictograms as selected?

5. Another user-unfriendly thing of the tutorial, is the bit about disabling the paste if some element apart from the diagram is selected. The user typically selects some elements, type Ctrl-C, Ctrl-V in sucession, and expects that the selected elements are cloned. Of course, this can be just an idiosincracy of the tutorial, but I wonder why it was implemented in that way.

I've playing a little with Copy/Paste features. The basic support is quite
nice and ingenuous. Some issues/observations:

1. The tutorial seems to assume that one will do just a cloning of the
pictogram but not of the Business object. It should be clear that this is
not necesary (I'm not even sure it's typical), one could also want to clone
the business object.

Michael: I added a note in the Copy&Paste section of the tutorial on that.

2. The copy/paste inner working does quite dark magic (for me, at least) to
place an EObject in the SWT clipboard, using the URIs of the EObjects (I
would have expected something simpler, more like an
serialization/deserialization, but I don't kwnow anything about SWT
clipboard, and little about EMF).
This has some hidden implicancies: one must not copied pre-cloned detached
objects, for example. Further, perhaps the tutorial (or the javaDocs) should
mention that the canXXXX() methods in the Features should be as light as
possible, in particular the canPaste() method is called a lot.

Michael: Hm, the way the clipboard is implement was simply taken over from
our previous implementation on our MOF-based modeling infrastructure. There
it was natural to implement it like this. Maybe in EMF a different
implementation would make sense, not sure about that.
Regarding the performance of the canXXX methods I added a note to the docu
page.

3. Because of that dark magic (I guess) the type of the content placed in
the clipboard seems to confuse the rest of the workbench. For example, if I
copy a graphical element (in the tutorial) and go to the Project Explorer,
the "paste" menu is enabled - this is slightly incorrect, compare with what
happens when one copies some text in a text editor.

Michael: Hm, you're right. What happens is a little irritating; would you
open a bugzilla for this?

4. For simplicity, the tutorial places the paste objects at the origin. I
tried the more typical behaviour, placing the objects at some offset from
the original. It basically worked, but it revealed a little issue: if
several objects were involved, only one of the new objects is selected after
the paste. This is atypical and frustrating, because one frequently wants to
move together the set of cloned objects.
Should I enter a bug?

Michael: For M3 we enhanced the paste context with the location information,
so users can also paste their stuff to the mouse location. The tutorial
shows how to do that. Selecting objects after feature processing is always
restricted to at most one object. An enhancement request should target that
completely; feel free to open one.

BTW: Is there some programmatic way of marking some pictograms as selected?

Michael: you can select them in the editor:
DiagramEditor.selectPictogramElements(PictogramElement[] pictogramElements)

5. Another user-unfriendly thing of the tutorial, is the bit about disabling
the paste if some element apart from the diagram is selected. The user
typically selects some elements, type Ctrl-C, Ctrl-V in sucession, and
expects that the selected elements are cloned. Of course, this can be just
an idiosincracy of the tutorial, but I wonder why it was implemented in that
way.

Michael: This is just the way it is implemented in the tutorial for showing
how to restrict copy and paste, without having much focus on usability.

Michael: Hm, the way the clipboard is implement was simply taken over from
our previous implementation on our MOF-based modeling infrastructure. There
it was natural to implement it like this. Maybe in EMF a different
implementation would make sense, not sure about that.

Some related material that might be useful/inspirational... in some distant future

Michael: For M3 we enhanced the paste context with the location information,
so users can also paste their stuff to the mouse location. The tutorial
shows how to do that. Selecting objects after feature processing is always
restricted to at most one object. An enhancement request should target that
completely; feel free to open one.