I like it. However I'd like to keep the option for a family designation. For simple colorspaces I see this as great way to simplify things. The family designation is still useful for instances like in IIF:ACES where the 10 and 16 bit ADX transformations are significantly different.

 
Yeah I can see 'family' would be really useful for grouping colorspaces based on purpose which could be as abstract as the profile builder would like. In the examples I couldn't see a case where family wasn't being used for bit-depth, but I agree it should stay. I agree if a bitdepth change significantly changes the transform required, this would suggest a different !<ColorSpace>.

For differences in bitdepth, I guess the usual case will be buffer A at a certain depth and buffer B at a certain depth, give me the transform from color space A -> B.

I was thinking something along the lines of:
ConstProcessorRcPtr processor = config->getProcessor(
    OCIO::ROLE_COMPOSITING_LOG,
    OCIO::ROLE_SCENE_LINEAR,
    OCIO::BIT_DEPTH_UINT10,
    OCIO::BIT_DEPTH_F16);

This would give you back the correct 10ui log -> f16 linear, without needing to mess around with colorspace names. This would likely end up looking a bit different with the 'context' ideas Jeremy and I chatted about.

Under the hood the colorspace could define the family implicitly from the name.

The SPI examples use the family designation in a very simple way. I could see a reason to place all video space transforms under a single family, for example. This could results in a family with 2 colorspaces that are named differently with the same bit depth.

 
Could you see a colorspace existing in two families? maybe we could have ',' separated tags which would allow for some powerful grouping of colorspace, I'm guessing families are mostly used for UI purposes, ie give me list of all 'video' color spaces. These would be similar to 'tag clouds' www people use to have items in multiple categories / groups.

eg.
- !<ColorSpace>
   name: vdhd
   family: video, hd
   ...

- !<ColorSpace>
   name: vdntsc
   family: video, ntsc
   ...

Maybe that's just a little bit two much over-engineering, for simple grouping.

.malcolm