There is an interesting thread on twitter (that perhaps would be better suited to being discussed here).
I’d like to at least focus on this response by @fmohus
I’ll quote it below for longevity.
I’m sure I should understand the aspect of “backwards compatibility” better. This topic did briefly arise in the last summit, with a notion that perhaps as long as “obsolete” concepts could be structured into a new concept, that concepts might be deprecated and made obsolete.
Certainly https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ suggests that major releases can break compatibility.
I’m certainly an advocate of removing say the IfcRoot inheritance of relationships The non-permanent GUIDs
Is there any resources or explanations that explain exactly what the requirements are around backwards compatibility?
Many interesting thoughts, well worth considering for
#IFC5 , but keep in mind that #IFC is also an archival format that needs backwards compatibility - In Norway it is even formally National Archives accepted (see §5-17 litra j in this regulation: https://lovdata.no/dokument/SF/forskrift/2017-12-19-2286 …)