One suggestion - allow top level Dictionaries:
The example given in the docs allows you to create a list of up to 4 sets of heart rate zones, and tag each one for a different sport. But there's nothing to stop the user tagging each one for the same sport. So currently it produces an array like this:
[ { "activityType" => 1, "zone1" => 85, ... "zone5" => 160 }, { "activityType" => 0, "zone1" => 92, ... "zone5" => 200 }, { "activityType" => 1, "zone1" => 90, ... "zone5" => 180 }, ]
A really useful enhancement would be to allow Dictionary properties too. Then require the first contained setting to not have an id. That setting becomes the key to the dictionary. So drop the "activityType" id (and change the property to "dictionary"), and now it produces:
{ 0 => { "zone1" => 92, ... "zone5" => 200 }, 1 => { "zone1" => 90, ... "zone5" => 180 }, }
and the UI can take care of not allowing duplicates - you select which config you want to add/update via a drop down. If it doesn't already exist, it gets created, and if it does exist you edit the existing one, rather than creating a new entry (as the current editor would).
----------------------
A second suggestion is to allow the elements to be Arrays, rather than dictionaries. This could save a lot of memory, and make the settings easier to use in some cases. Again, I'd suggest just dropping the ids from the configs. Note - this doesn't conflict with the above suggestion. So eg if we now drop the ids from the zones, we get
{ 0 => [ 92, ... 200 ], 1 => [ 90, ... 180 ], }
which is probably how the program is going to use the zones anyway - so it saves a conversion step.
-------------------------
Finally, If there's only a single setting, with no id, just expose the bare object, rather than wrapping it in an array or object. ie, if we take the last example, and just have one zone (ok, it doesn't make sense for heart rate zones, but it does for some things), we get:
{ 0 => 92, 1 => 90, }
Or going back to an Array property, it would look like:
[ 92, 90, ]