On an existing memory, sa y a straight USB memory, If I change the MODE from USB to DIG, is if I change the MODE from anything to DIG, nothing happens, and the column still says USB. The debug log 
 shows it is trying to set the right value, but something else is going on under the covers. No error messages in the log.

Then, again on an existing memory, again USB, I change the DATA MODE from N/A to USER-U. Magically the MODE becomes DIG (who did that? Not me!) Now I can't put the mode back to USB, nor can I 
 set the DATA MODE to  N/A.

 I can change an existing , non-data mode to any other mode that has DATA MODE as N/A, but as soon as I try DIG, I am stuck.

The UI does a set_memory() with what you changed and then immediately does a get_memory() to refresh the view. So if you choose something in the UI and it appears to "not stick" or change to a different value, it's because your driver returned it when the UI went to refresh after the edit.

Your problem sounds like you're always setting the mode value in radio memory based on the "data mode" value. So after a UI edit of mode, your driver probably sets the mode in memory based on that, then goes through the extra values, finds "data mode" and then re-sets the mode based on *that* value. Thus, if you change only mode, it seems not to work because you're clobbering it later with the extra['data_mode'] value. If you change extra['data_mode'] that "works" but seems to override mode because you're honoring it all the time. Probably best to only honor extra['data_mode'] when mode is already set to DIG.

It's hard to say without seeing your code, so pushing what you have up to your PR would help. Someone else was asking me to debug almost the exact situation recently in a completely unrelated driver :)

--Dan