Actually all of this is not really a bug, but also not really good the way it is, I agree. But it is complicated, it has to do with the way FreeCAD works, which is made mainly for very clean dependency chains, and not so much for the dirty combinations we do in the arch workbench
- You have a cube, you put that cube into a group (site, floor and building are only special kinds of groups). Then, you build another object on top of the cube, that new object is not part of the group. For me that is normal. There is no reason why we should suppose that the user will want the new object to be automatically included into the group. Of course, in architecture work, things might be different, and we might want this in some cases. We could do that, for example, on Arch object creation, when an object is built from another, check if the base object is in a group, and if yes, add the new object to the same group. That is not too complicated.
- The tree representation is another problem. Basically the tree was not made to have several objects based on a same one. That is, several objects that will "claim" the base object as their child. What happens, in that case, is, on tree redraw, each object will "swallow" its children. The last one to do so will have the cube appear under it. This is a design intent of FreeCAD, and modifying it is probably out of question at the moment.
One solution would indeed be, as rockn suggests, remove the base object from the group first, so it has only one parent. But it will be impossible to guarantee that always (that each object has only one parent), because sometimes you specifically want two objects to be based on the same child.
Honestly I haven't found a good solution for this yet, apart from taking care yourself, as a user, to design things cleanly and separately. The panel rockn suggests might be good too, but I'm experimenting with something in the Path module that might serve for all groups...