Hi Marcel,
... MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
I introduced MCVersionName in 2011 as part of the work that unified the MCRepository hierarchy. At that time, external callers had become completely dependent on the only-used subclass, MCFileBasedRepository.
So the MCVersionName design was partly for maintaining forward-compatibility for older versions within the MC legacy, but also because it's the soundest and simplest design. The importance of capturing explicit structure in "names" that have them (e.g., filenames, version names) is underrated. MC should have harvested the de facto structure into its code in the first place, but even then, before the legacy, I don't think composition would've been the optimal choice. The requirement calls for a pure scalar value that can be serialized to and from a human-readable filename, but with API access to its structure which the MCTools needed to get off the ground (out of the ditch).
There are a lot of names. Composition would essentially require an unnecessarily heavy "ValueHolder" that would either need to be serialized or dynamically created all the time, disrupting the effieciency needed out of the (pre-Spur) tools of that time. Maybe some would argue that a bunch of extension methods on String is better, but I see domain-specific subclasses as merely a rarity, and not an anti-pattern.
Best, Chris