No matter how much you invest in the marketing of the IFC5, diven the scope of the change, it is a revolution and NOT evolution.

Using STEP modules would do this equally well.

Key point. Very hard to set when rebuilding IFC from the ground zero.

If is is more rich and granular, how can it be simpler?

Yes, building information is rich. That's why IFC is a rich (and inherently complex) schema.

The original objection against STEP was, that is it too semanticaly rich. Is this not a contradiction?

STEP is also language independent. You can use any programming language to work with it.

So, there will be the mesh AND the parametric definition. You can do that in IFC already by using multiple geometry contexts.

IFC schema only describes what is needed. Any simplification will mean data loss.

This is great, if we only want to support 3D coordination.

Yes, we do need a schema language to make any sense of the data. That's what STEP/EXPRESS does very well.

Both authoring tools and viewers already do this on a large scale.

IFC has been using mapped geometries since ever. Nothing new or improved.

This is important! Triangulated mesh is great for some of the use cases, but not for all. Do we want to constraint the use of IFC just coordination? Why do we need any streaming capabilities in that case?

While it is possible to store one schema in many serialization formats, it decreases the reliability of the implementations. To claim IFC support, all the vendors will need to implement all the serialization formats with their quirks and workarounds. The final implementation matrix will make the IFC support very expensive and error prone, contrary to the goal of making it easier for startups and ISVs.

Major SW vendors will love to simplify to the point where the only suitable way to exchange their data is their proprietary format.

Here, USD is claimed to be flatter and simpler. Let's see later.

All very well defined in STEP.

These files will be much bigger than STEP files, at least twice. How does this help interoperability?

This already exists in IFC, where property can be overriden by the instance, while instances inherit properties from the type.

How can IFC support distributed authoring and collaboration, if it doesn't support the wide range of geometry representations used in the industry?

If we need to support distributed collaboration, it would be very easy to define a "patch" format for IFC.

This is just a statement with no guarantee or reasoning.

If the IFC schema was split into STEP modules, implementations could equally just skip all the data from the modules they were not interested in.

Using new relations, this is perfectly possible in current IFC

This is what IFC as STEP already IS! The entity itself is merely ID, name and description. Everything else is referenced directly (geometry, placement), or indirectly (all the relationships)

For sure, there was a REASON for the restricted adoption. It is usually better practise to follow successfull and widely adopted standards, rather than those proved not usable or useful.

Fixed schema is crucial to keep the data exchange reliable. Flexible schema means low level of implementation confidence.

This is the case for the native authoring tools. Is this the case for IFC? Do we envisage the existance of a master IFC model? IFC5 also aims to simplify the geometry definitions. Will this distributed system just work with meshed geometries?

As part of the standard, adding new entity attributes to the end doesn't break the schema backwards compatibility. In the other direction - making significant changes in any contract, any modelling language will cause breaking changes for those using the contract.

This is caused by the way buildingSMART has been using STEP. It has native support for modules. buildingSMART had made a deliberate choice of not using them in past.