IfcMaterialProfileSetUsageTapering cannot specify the second profile at the type level

[Moult]

For all other material sets, they can specify the profile(s) / layer(s) at the relating type. Then, all occurrences of that type will have a material set usage pointing to that material set, and the representation is expected to comply by either using the same profile as its extrusion profile or have the same total layer thickness.

Except for IfcMaterialProfileSetUsageTapering. There is no IfcMaterialProfileSetTapering equivalent, which means that the type can only be a regular IfcMaterialProfileSet which defines only one (potentially composite) profile. However the usage requires 2 profiles (start and end).

This is inconsistent with regular material sets and set usages, and implies that there is no way to predict the other profile of the occurrence. In theory, every occurrence can then point to a completely new instance of IfcMaterialProfileSet that isn't referenced anywhere else. This sounds semantically dubious (imagine a model full of profiles tapering to random other profiles all being the same type).

One proposal is to introduce a IfcMaterialProfileSetTapering equivalent.

Another proposal is to deprecate IfcMaterialProfileSetUsageTapering as a complex usecase that doesn't fit the "standard case" of simple extruded profiles.

[aothms]

Another potential issue is that this approach doesn't scale to more than one profiles. In my view, all these different approaches of decomposition should be handled generically. We just need to figure out a way to instantiate aggregates (we kind of started with this already for ports), as all these material sets, compound profiles, etc. are basically just workarounds for the inability to instantiate aggregates.

https://speakerdeck.com/aothms/ifc5-adequate-complexity-maximum-reliability?slide=14

[Moult]

all these material sets, compound profiles, etc. are basically just workarounds

Completely agree for later stage BIM models.

For early stage BIM models however I think the material sets address "standard case" (low LOD) modeling very well and it would be cumbersome for all parties to have aggregates as the number of objects can easily double or triple. So I see this as a contrast between early stage "standard case" and later stage "elemented case" (i.e. the aggregation you propose).