Protective-device Psets: overlaps, redundancies and single-property sets (please consolidate and define a deprecation path)

## Context
When modeling breakers/motor protection in electrical, several Psets partially overlap in scope and property semantics. Some Psets carry only one property, others repeat similarly named concepts with slightly different wording.

## Problem
- Overlap/redundancy among (examples, not exhaustive):
- Pset_ProtectiveDeviceTypeCircuitBreaker
- Pset_ProtectiveDeviceBreakerUnitTypeMotorProtection
- Pset_ProtectiveDeviceBreakerUnitTypeMCB
- Similar concepts (e.g., rated/tripping currents, breaking capacities, characteristic curves) appear multiple times with different names or descriptions.
- Single-property Psets increase noise and schema surface without clear benefit.
- Tooling and IDS authors must map/merge properties ad hoc, which creates divergent practice.

## Why this matters
- Interoperability suffers: two models can be “correct” yet incompatible.
- Affects domain authors (electrical) modeling distribution boards, quantities, and geometry.
- Causes divergence between checkers/viewers, and slows adoption.
- IDS/library publishers cannot provide clean, reusable profiles.
- Projects risk losing semantics during conversions.

## Proposal

1 Consolidation & naming
- Identify duplicates and merge into fewer, cohesive Psets with consistent names and ISO/IEC terminology (e.g., align with IEC 60947/60898 domain terms).
- Introduce clear definitions (what each property means, units, allowed values).

2. Deprecation path
- Mark superseded Psets (and properties) as deprecated with a cross-reference to the replacement and an expected removal timeline.

3. Usage guidance
- Publish short guidance showing which Pset applies to which entity/type (device type vs breaker unit, etc.), with one canonical place for each property.
- Provide an IDS snippet that references the consolidated Psets so vendors can validate consistently.

## Questions for maintainers
1. Can we start a focused review of the protective-device Psets with domain experts to propose a concrete merge list?
2. Are there constraints that require keeping separate Psets (e.g., historic mappings) — if yes, can we still deprecate duplicates?

## Minimal repro / evidence
- A simple MCB device currently requires properties from multiple Psets with overlapping semantics. Different tools pick different Psets; exchanging the model drops/duplicates data.

## Affected
- IFC 4.3.2.0 Pset definitions, IDS authoring, bSDD mappings, vendor libraries.

---

_Thanks for your guidance and for pointing us to the right repo if this should be filed elsewhere._