Support intersection of properties for mixed class selection in iModel

[NemaAryan]

Package
@itwin/presentation-components
@itwin/components-react

Issue
We use a custom property panel UI (not @itwin/property-grid-react), and the data source is PresentationPropertyDataProvider with unified selection. So the content returned by PresentationPropertyDataProvider.getData() directly controls what users see.

For mixed-class multi-selection, PresentationPropertyDataProvider.getData() returns union-style content (all properties from all selected instances).

For our workflow, we need intersection-style content (only properties common to all selected instances).

Why union is hard to use:
Attached screenshot uses Surface Region + Slab elements, which have strong intersection overlap and clearly show the extra-property problem in union output.

[grigasp]

IMO, using intersection of properties vs the union makes sense. What I'd like to avoid is some apps using intersection and others using union, though - I think the display should be consistent across different Bentley apps.

@jason-crow @simnorm @aruniverse, I'm interested in hearing your thoughts about changing the default behavior from "union" to "intersection".

[aruniverse]

imo this could be seen as breaking, esp if the default for yrs has been union
i see value for both use cases, why would we not just add an additional toggle like we do for hiding null value to hide non-interesection values?

[jjbeckman13]

Is there a way to make it configurable so that the user could switch between intersection vs union?

[jjbeckman13]

We should not change the existing behavior without validating this with users and providing some user-facing documentation explaining the change.

[grigasp]

why would we not just add an additional toggle like we do for hiding null value to hide non-interesection values?

@NemaAryan, would that work? We would keep "union" as the default and allow users to switch to "intersection".

[NemaAryan]

Our custom property panel uses PresentationPropertyDataProvider as the single source for property data, so provider behavior determines what the UI can show. A union/intersection toggle at provider level would solve our requirement.

[noelgonzalezjones]

I would support the toggle approach proposed by @aruniverse and @grigasp — keeping union as the default while adding a configurable intersection mode.

In viewer workflows, BIM Managers frequently multi-select elements across multiple classes (e.g. mixed structural types across disciplines) and need to quickly compare or bulk-edit the properties they have in common. The union output adds a lot of noise in those scenarios. An intersection toggle would let us show only the shared properties, which is what users actually need for review and QA tasks.

We already have display filters in the property panel (hide empty values, group by category), so a union/intersection switch fits naturally alongside those without introducing unfamiliar UX.

That said, I agree with @jjbeckman13 that validating this with users before shipping/development work starts to confirm it matches their actual workflows and mental model. Especially around whether intersection should be a persistent preference or a per-session toggle.