difference between applications implementation making it harder to create one config for all apps

Hello,
This is the follow-up issue of [my question on the OCIO slack ](https://opencolorio.slack.com/archives/C3R102Z50/p1722510182990629).

From the [the NanoColor OpenSourceDays24 recording](https://youtu.be/aR3RZEHownA) there was this bullet point which sparked my interest:
> No need to configure each app separately, all use the same config

Based on my personal experience with OCIO I have found that this is not really true. Despite understanding that this is the original OCIO goal, it doesn't seem it was achieved as what I feel is that in reality, every client application implemented a slightly different usage of OCIO which pushed us, config authors, having to do complex research and development on find what does each application expect to find in the OCIO config. This could just have been a documentation problem but it seems that each application took a different approach that may conflict with one another, resulting in configs that may be messier to develop and use for the artists.

I do not have an example for all DCCs but here is a few of specific issues:

- Redshift:
- [link](https://github.com/MrLixm/AgXc/issues/2): expect a mix of standard roles AND a colorspace with a specific transform structure
- substance 3d painter:
- [link](https://helpx.adobe.com/substance-3d-painter/features/color-management/color-management-with-opencolorio.html#ColormanagementwithOpenColorIO-OpenColorIOroles): expect 8 custom roles
- [link](https://community.adobe.com/t5/substance-3d-painter-ideas/color-picker-ocio-implementation/idi-p/14770781#M522) does not make use of the `color_picking` role
- blender:
- [link](https://projects.blender.org/blender/blender/issues/124544): use the first Display's View to render their color-picker preview
- houdini:
- [link](https://mograph.social/@compfu/115688717661915571) some asumptions around file rules which may affect the scene if the config is edited during a project

With probably some other issues in other typical VFX applications (usually roles-related).

Also one of the other issues is the lack of `Look` support in the GUI for most if not all client applications. Thus we have to create Views with the looks baked which are going to be redundant for applications supporting such behavior like Blender.

On the same topic, we have the "missing display/view colorspace export in GUI" that appeared after the adoption of OCIO-2. Because this version offered a new way to build your Display/View, you didn't have to build a single distinct colorspace for your View and could instead have it built on the fly from a combination of ColorSpace and ViewTransform. But because applications didn't catch up directly we had an awkward moment where artists used to select the display corresponding ColorSpace in the GUI menu (that was listing ColorSpace entities), couldn't find a ColorSpace matching their "view-transform" anymore. Like in Nuke where you had to put an OCIODisplay node before your Write node, instead of relying on the Write node `colorspace` knob.

---

Hopefully, you see my point, which is that combining all the applications, at various versions, with various OCIO API version and it starts to make sense having to create one config per application just in case.

I unfortunately don't have many solutions to counter-balance the issue I'm exposing, neither think that there is anythign specific to fix in OCIO directly. But perhaps it will be useful to expose such problems for the future and maybe helping application vendor handling them ?


Let me know if anything is not clear or does not make sense.
Cheers,
Liam.

这是一次跨应用兼容性讨论，而不是实现任务，并且没有确定任何仓库文件或测试。首先查看链接的 Redshift、Substance 3D Painter、Blender、Houdini 和 OCIO-2 行为示例。要视为完成，需要明确的范围，以及可执行的互操作性指导、要求或文档。

由索引模型根据 Issue 内容生成。