Scott, I feel the discussion highlighted the fact that our design priorities and usage patterns seem quite irreconcilable within one class. More so, the discussion seems to have introduced new requirements like old-standard-compliant low-level copying, ability to create an uninitialized uuid instance, efficient and economic initialization from hard-coded uuids (mentioned by Adam) that might not have been addressed in Andy's implementation yet. Therefore, I feel that yours and Dave's suggestions of "a low-level representation class as well as a higher-level wrapper with stronger invariants" might be the best approach to cater for those widely differing deployments. At present it'll probably be Andy's call if/how he decides to incorporate your suggestions and package it all as two classes or to discard one or the other. Ideally, I'd probably like to see two classes. Something like boost::aggregate_uuid and a boost::uuid wrapper as I suspect that wrapper to be the most common deployment choice. If the decision is made to go only for one aggregate-type uuid, then I'd like we make sure the documentation spells out how to "objectify" (what'd be a better term?) that aggregate type. Best, V. P.S. As a side note, I am glad we had the discussion and I appreciate you kept it going -- it forced me to have a fresh look at aggregates from a completely different perspective. Due to the specifics of my work I am unlikely to deploy any of that in the short timeframe. However, it surely enriched me. Thank you.