Bug or Undocumented Feature?

It may be intended behavior, but it wasn't what I expected. Here's a dumbed-down description to isolate on the important bits.

1. I have a custom device configuration text field that is set to default value "0".
2. In getDeviceConfigUiValues() , I check to see if the value is the default value.
3. If it's the default value, I populate it with a value from the server (in this case, lat/long).
4. The next time I open the config dialog and edit the text field, changes to these fields aren't saved (but changes to other fields are saved properly).

Although the textfield established the control as a string, when the valuesDict (changed in getDeviceConfigUiValues) was returned, the prop type was set to real. When trying to change the prop later via the config dialog, changes to lat/long wouldn't take because the new value was a string. Once I changed my code to write the lat/long values to valuesDict in string form, I got the behavior I expected. By inadvertently saving the data to valuesDict as floats, I pretty much locked down that field from future changes. Chased my tail for a while on that one.

[matt (support)]

Definitely sounds like a bug. Were any errors logged to the Event Log window during the process?

No errors posted to the log file whatsoever. That's why it was so tricky to find.