I'm not sure what promoting the reference colorspace to something
special - either in the API or the format - buys us. Can you provide
details on how this would make things simpler (or any other benefits
you see)?

Coming clean, I have to admit that in our internal SPI Color library
(the predecessor to OCIO) we actually never exposed a function call to
query the name of the reference colorspace in 7 years of use. There
was always a call to query scene linear, but the fact that this also
happened to be the internal profile connection space was never
relevant to end users.

My thought in adding it to OCIO was for completeness sake when
spec'ing out the ROLE listings, but until it has an obvious use case
perhaps we should remove ROLE_REFERENCE? It can always be added back
in, when needed. (This is probably the API corollary to premature
optimization, where you speculatively add a feature that only adds to
confusion and in practice is never used).

I do believe that understanding what a particular color configuration
uses as its connection space is critical, but in my opinion this is
best solved textually at a configuration level (i.e. config docs).

Thoughts?

In terms of your specific suggestions, I think I would prefer to have
the reference color space just be another colorspace, with no
particular distinction. While it doesn't have a transform block, it
does have all the other colorspace markup, so it really does feel
'colorspace-like'. I could also foresee a situation where someone was
using the connection space implicitly, and it wasn't intended to be
either named or used by the end user. (We havent done this, but I see
no reason to disallow it).

Addressing the extra nesting added to your .ocio transform block, your
version doesn't strike me as any more readable.
old: to_reference.children
new: to.reference.children

Isn't redundant nesting bad?

Perhaps there is a better name for the "to_reference" and
"from_reference" values? I'm totally open to revising that enum name.

-- Jeremy