Thanks @waddink - I can see the value. Here are two reasons:
Given our experience with data publishing over the last couple of decades, we know that different data holders manage and can provide the same information in different ways. So long as we understand the implications of the CMS being identified, we can infer up or down from institution to collection (just as we often do from dataset to specimen/occurrence or from checklist to species).
More importantly, I can see ways that this could progress beyond simple identification of the CMS and version. It could be or could serve as an advertisement of the digital services available for the collection offers that may exceed what is available through a static CD document or through standard data downloads. Imagine a situation where we defined a set of standard (TDWG-developed) service types that could be implemented by a CMS (retrieve digitisation summaries, submit specimen annotation, initiate loan request, etc.). This could help GBIF, DiSSCo, iDigBio, etc. to start bridging the gap between push-based data publication and the more interactive world we all want. The CMS can offer services that enhance its digital accessibility and value. The aggregating infrastructures can supply the glue that uses these service definitions and showcases the collections’ capabilities. New specialist tools could be built on the same framework. Effectively the CMS to aggregator interface can become a many-to-many client-service framework.