It’s an unfortunate fact that the Academy’s Color Transformation Language (CTL) hasn’t garnered the amount of support that is required for this to remain as the singular official implementation of the ACES transformations. Rather than gathering the community around a single point, it has instead forced most adopters to re-implement the system in their own domain.
We as a community need to explore the best way to define the ACES transforms in one or many universal programming language(s), and provide means for a test framework to ensure equivalence if the official implementation language becomes fragmented.
I’ll also add my two cents, that OpenColorIO’s problem set fits perfectly in this domain. A more holistic solution, in my opinion, would be to push development support towards a pure implementation of ACES in OpenColorIO (which there is already a desire and plan to do so), so any adopter need only link against the OCIO libraries to fully support ACES: whose task it is to directly process the pixels on the CPU and provide the correct shader representation for the GPU. So if the ACES transforms are “officially” defined as OCIO Ops, then both projects benefit from the combined resources and attention… (stepping off the soap-box now)
If this isn’t feasible or wanted, then ideally there would be a solution akin to using the LLVM/SPIR-V intermediate representation where one “master” implementation (perhaps remaining as CTL if an LLVM front-end is written) would be maintained and many child representations could be generated as needed.