I would disagree to the proposed change, since it creates a non-upward compatible change in regard to IFC4.3. The SPF notation would change from [] "empty set" to $ "non asserted set" and at least under previous considerations this is not upward compatible.

(the original SET[0:?] also comes from P42).

Personally I would recommend to wait until the next major IFC release to make this kind of changes.

No worries, we will revert it for the submission. This was just for the test run. Thanks for the feedback.

I understand, the problem is that SPF serialization would suffer and old files that require an empty set would fail in deserialization since according to this spec an empty list is not allowed. A question though, what about OPTIONAL SET[0:?]. This way both $ and () are allowed.

A slight correction though, part 42 actually has SET[1:?]:
since the definition is a bit different and there is no separate outer boundary attribute. One boundary has to be always in the set. I don't know, however, if this was changed or when it was changed but the current state in part 42 seems to be one mandatory SET[1:?].

IFC is also a bit inconsistent further, apparently two entities are referencing this one curve_bounded_surface definition from part 42:

1. IfcCurveBoundedSurface
2. IfcCurveBoundedPlane

EDIT: Realized this one was not even merged. I was careful. Funny, I know.