I could interpret your post either as meaning “I don’t know what type of data attribute-X might contain,” or, “I don’t know what attributes (and what attribute-names) there might be.”   I’m taking the second interpretation, and therefore concluding (IMHO) that what you are talking about here really doesn’t qualify to be an object attribute (property) at all.

Instead, I see it simply to be a piece of data that you wish to store-and-retrieve by name, in a store that is associated with a particular object.   You might wish for the object to provide this service in such a way that it is capable of detecting (whatever you consider to be ...) errors, and to throw errors appropriately.   But, basically, these are just named pieces of data, and the object is providing you with the robust, centralized service of storing and retrieving them.

You could, for instance, define methods such as:

$obj->set(keyname, value)
$obj->get(keyname [, default])
$obj->must_get(keyname)

It is, of course, possible to use AUTOLOAD tricks to auto-create such accessors on demand, but I suggest that these tricks hide the designer’s intent ... and make it difficult to detect tpyos, which laed to errosr in yuor cdoe taht do not reuslt in the copmile time erorrs taht wolud enbale you to qucikly sopt them.

If the object needs “to store arbitrary values by arbitrary keys,” perhaps also subjecting those processes to various error-detection steps (such as, discerning whether the keyname is legitimate), then that is a service which the object provides for its clients.   Not a property.   IMHO, true properties are never dynamically created nor dynamically named.   In my experience, that’s a rabbit-hole you don’t want to go down.