1) PropertiesAttributeDefinition, basicly complex attribute with key & value
2) sub resources, where key = name of resource and there is only one attribute under it with value, for example see PropertyResourceDefinition and its usage. This is quite common
Consolidation on these two would already be a great help. But I would even take it further:
Why do we have complex attributes (ModelType.Object, your case 1) at all? IMO the most straight forward approach would be to only allow for attributes to be simple types (ModelType.<String|Int,Bool,etc>) and enforce any ModelType.Object to become a sub resources (addressable).
Mangling complex types into attributes creates a lot of ambiguity and is the main driver for creating edge cases and workarounds.
A word on backwards compatibility:
We've done a fine job so far, but if we get a chance (WF.Next) we should try to correct the model and if necessary break compatibility.
regards, Heiko
my intent is/was to unify most of this under #1 & #2, there are some good use cases for #2 but in most cases when you need any special handling of each and every property #1 works best and is simplest to use.