If you use the OCIO environment variable (and point it to the .config file) instead, it should be fixed. This happens because internally, we do some name matching (trying to match the chosen color space name to something appropriate, which introduces the issue of names not being recognized). When using the variable in such cases, however, there’s a fallback to what’s declared in the config file, hence why it works. Also, it renders fine on your end, because you use sRGB, not sRGB Encoded Rec.709.
I just dealt with this whole choir of ocio in multiple dccs. Everyone has their own now which is just annoying. For multiple dccs OCIO env variable in windows system is a bad idea actually (if that’s how people intend to set it up). Reason being is houdini, maya, nuke and likely max all ship with their tailored ocios now. A better way of handling this is declaring ocio as a per software env variable. For now we had to write a cmd startup script for each dcc which loads their own ocio. it works well, however if you use this method then rendering on the farm requires you to have the same approach, that is instead of pointing to mayabatch.exe for example, you need to point to your cmd script that then calls mayabatch.exe while also loading the same ocio variable.
