> My assumption was that the enumeration was used in an attempt to avoid clashes with user-set property names (before ol.Object got a dedicated storage object).

The initial implementation of `ol.Object` was virtually identical to `google.maps.MVCObject` which used similar property names to avoid clashes. Specifically, this allows inheritance in application code from `ol.Object`. Without explicit property names, `ol.Object`'s properties tend to get renamed to short names like `a` or `b`, which of course causes conflicts with any base class using properties called `a` or `b`. More generally, the compiler renames properties so you cannot guarantee that any property name won't cause a conflict with application code.  The specific property names are an attempt to choose property names that are highly unlikely to conflict with the application's property names. Based on this, although there is a [dedicated storage object](https://github.com/openlayers/ol3/commit/d6ff58305de50954fd68506f3cde4c411c0f72ac) I would be tempted to use `_ol_values` as the property name for this object, otherwise `values` might get end up getting renamed to something that conflicts with an application property.