Currently, the multi-selection (using ctrl/cmd-click) is unrestricted and can be fully heterogenous in item types (e.g. it can contain both a container and component). This is problematic in at least two areas:

• What should happen when drag-and-dropping a (very heterogenous) multi-selection?
• Makes the future "merged" selection panel very difficult (related: Displayed "merged" view of multi-selection in the selection panel #4251)

We should change how the multi-selection behaves to make the above easier to implement and more predictable for the user.

TL;DR: do like figma

First, we should distinguish two classes of items:

• Layout items: container and space views
• Data items: entity tree and components

Given this definition, we should introduce two major restrictions to what a multi-selection can contain:

• It must be homogenous in layout vs. data items (ie. can't contain both a container and an entity).
• It must only contain items leading to disjoint subtrees (ie. you can't select both a container, and a space view contained in said container).
  • In particular, when the user multi-selects A that is some parent of already-selected B, this should happen:
    • A is added to the selection
    • B is removed to the selection...
    • ...but B is implicitly selected by virtue of being a direct or indirect child of A

The UI should reflect the above by introducing a "subdued" selected state for children of selected items (basically like Figma).

Related:

• Highlight items related to the selected items #5257

Blocked by:

• Enforce homogenous multi-selections #4887

Finally, we should introduce an "extend selection" behaviour (shift-click) that is aware of the above.