Ticket #3073: "Labels & Attributes" tree mix-up randombly elements

[Kunda1]

issue #3073: "Labels & Attributes" tree mix-up randombly elements
Forum thewad to discuss this ticket.

[Escain]

Here are two files that mix the tree view.

To reproduce the error:

- Open eye.fcstd
- Open Sphere.fcstd
- Select the root item of Sphere and press Ctrl+C
- Choose "No" to make a simple copy
- Double click the file eye.fcstd to select it.
- Ctrl+V to paste the sphere simple copy

Result: The element "Camera Original" is now a child of "Sphere"

[wmayer]

- Choose "No" to make a simple copy

Note, when omitting the referenced objects then the copied root object is still no simple copy. If a simple copy is that what you want then you should better use the command "Create simple copy" from the Part workbench.

This is what happens:

1. the object Sphere has two children Sphere shape and Sphere hole. The internal name of the former is Fusion001
2. the document Eye has the object Camera original whose internal name is also Fusion001
3. when copying & pasting Sphere from one document to the other then it still knows that it references an object internally called Fusion001 and that's why Camera original becomes a child of the new object Sphere002

The result might be unexpected but is not a bug and there are use cases where this behaviour is expected, e.g. when cloning a root object without cloning its children.

So, this issue falls into the category a feature, not a bug

[Escain]

Claim 1: Ctrl+C/Ctrl+V is one of the most basic copy mechanism, so it should apply to the most basic and easy to learn copy capability/feature.
Claim 2: To keep coherent behavior, if I may "non-deep-copy" without the children existing, it should provide always the same expected result even if some name is re-used. This translate to: a) make a simple copy, b) warn the user when a name will be merged, c) only allow to copy when all children names exists.

I understand that a bug could result in a nice feature for an experts aware of it deep working mechanism, so the question is IMO:
- Is this mechanism a de-facto standard in the industry?
- Is this mechanism user-frendly and easy to grasp?

If yes to both->keep it, if yes to the first-> keep it, otherwise I strongly recommend to improve it.