Hi,
Sharing that as another follow-up to the meeting and topic for discussion and clarification:
The context here is an implementation where the LMTs are immutable, i.e.an OCIO pipeline with no controls. Don’t ask why three LMTs like that, I just know that is possible 
The obvious problem with Pipeline 1 is that with no opt-out possible from Gamut Mapping, i.e. the small green boxes, the region above the threshold is compressed 3 times.
Important, to keep in mind is that the ACES transformations are immutable, i.e. without user parameters for obvious simplicity of implementation reasons. Metadata tracking is hell, we all know that very well. We, thus, cannot really have a default that states that every AP0 to AP1 transformation is Gamut Mapped with an opt-out, unless we double the shipped LMTs count. We could certainly do that but it would be a rather non-elegant architecture that the TAC would not be happy with!
Pipeline 2 is what I think we should be looking for, i.e. a dedicated, optional, Gamut Mapping LMT that can be inserted, at any point in the LMT stack. User is then responsible and in control of what is happening. The implementation would be super simple and it would be relatively easy to change the operator without having to version up all the LMTs in a backward-incompatible way because we have tweaked the operator.
This Virtual Working Group is sandwiched in-between the IDTs and RRT/ODT portions of the ACES pipeline, it is dependent on the future findings of the Virtual Working Groups that will be combing them soon and nothing says that there will not be revision on the Gamut Mapping operator.
Cheers,
Thomas
PS: I had an unrelated feeling that we should check what is happening when we compress the values with respect to DCI-P3, it is entirely possible that the operator will prevent reaching out the maximum P3 values.