Geometry: SurfaceOrSolidModel — list/placement inconsistency and “mixing” rule (exclusive vs. non-exclusive) for items within one IfcShapeRepresentation

**Labels:** `geometry`, `representation`, `consistency`, `docs`, `validation`, `clarification`

## Problem
Concise description of the inconsistency / ambiguity discovered while implementing an IFC 4.3–based use case.
While fixing a validation error, we switched a representation from SweptSolid to SurfaceOrSolidModel to host both tessellated and solid items under one IfcShapeRepresentation.
Two issues arose:
1. Listing inconsistency: SurfaceOrSolidModel appears in one list (representation types) but is missing in another place where we’d expect it to be listed/allowed for Views/ShapeRepresentation Types.
2. Mixing semantics unclear: Does SurfaceOrSolidModel allow mixing different item classes within the same IfcShapeRepresentation instance (e.g., tessellated + solid), or must items be homogeneous (“exclusive-or”)?
- The bSI Validation Service currently fails when mixed items are present (unless using certain supertypes), suggesting an exclusive interpretation.

## Why this matters
- Impacts interoperability and/or validation reproducibility.
- Affects domain authors (electrical) modeling distribution boards, quantities, and geometry.
- Causes divergence between checkers/viewers, and slows adoption.

## Questions for maintainers
1. What is the intended, normative behavior? (Please confirm expected reading of the spec.)
2. If the current artifacts (schema, docs, lists, VS rules) disagree, which is authoritative?
3. Is a spec/IDS/rule update warranted? If yes, what deprecation/migration path do you recommend?
4. Can you point to the exact clause / EXPRESS / IDS draft that should be implemented?
5. Is SurfaceOrSolidModel supposed to be allowed in the relevant ShapeRepresentation type lists for the concerned Views? If yes, please fix the omission; if not, please clarify the normative scope.
6. What is the normative rule for item mixing within a single IfcShapeRepresentation of type SurfaceOrSolidModel?
- Exclusive (all items must be of the same item class), or
- Non-exclusive (mixed permitted), or
- View-dependent rule?

## Background & impact
- Implementers need clear, testable rules. Today’s ambiguity yields divergent exports and validation failures.
- Allowing mixed items may reduce duplication; forbidding mixing enforces stricter partitioning (multiple representations).

## Environment
- IFC: 4.3 (implementers’ view)
- Authoring/checking tools involved: internal exporter, bSI Validation Service (beta), IfcOpenShell/BlenderBIM-based viewers, others.
- Domain: Electrical (Distribution Board), plus general geometry rules.

## Proposed resolution (for discussion)
- Align the representation type lists to include or exclude SurfaceOrSolidModel consistently.
- State the mixing rule explicitly (exclusive vs. non-exclusive) and rationale.
- Update Validation Service rules and provide a minimal example for both allowed and disallowed patterns.

---

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