publishing an intermediate release 3.1.0?

Hmmm, if I see the black box instead model icon, I understand that I haven't the model icon. If I see the default icon instead model icon, what I will think? Something wrong? Model setting are reset? Something else?

Possible, will be better place question mark or 'icon missed' in black box.

I would retain the setting, but I don't even mind the black box if the file is missing...

As for me, I don't see any need to change anything with icon. I don't like 'smart' software that changed settings without my permission.

FYI, I'm slowly getting through the changes now. I'm all the way up to beta02 now So far, everything looks ok. I've seen a couple things I would do differently, but nothing major. It just takes time to look at each patch and understand what it does.

Ok,
It looks like I hit the 1st real snag in beta06.
I don't like the tr_n function at all.
I understand what you are trying to do, but I'm really not happy with this approach.
If we go this route, it would be better to just have an snprintf function., but there is a reason I don't have it available.
Another possibility is a static checker to find these issues.
Sadly this change will make it much harder to pull in changes after beta06, since I'll need to manually do a diff and fixup (if I pull in beta06 and then revert, I end up with a huge number of lines being touched which makes 'hg annotate' basically useless, and it is something I use a lot)

I'll need to think on this before I can proceed.

Edit: And now I see the various string variables were replaced with a single one.
This one is probably okay, though it does use more RAM than the original solution. If I find a solution (that i like) to resolve the issue that resulted in the creation of tr_n, I'm not sure I need this though.

I modified the printf code to add snprintf support based on this:
github.com/mludvig/mini-printf
It adds less than 100 bytes of code.
I think that using snprintf will negate most of the need for tr_n. (the snprintf isn't really POSIX since all strings are null terminated)

Of course using this solution will mean a lot more testing is needed to make sure it is as robust as what rbe did, but it looks like a better solution to me.

I've committed changes that should be equivalent up to beta-09 (but not including the 'StringReserve' merge. I've replaced all of the tr_n() calls with proper snprintf() instead.
I'll continue moving forward analyzing and committing with the other changes.

Unfortunately, you won't be able to do a 'merge' since I couldn't do a 'pull' on rbe's repo. Until I'm done, I don't recommend rebasing on my repo, as it will just duplicate work.

I'm just about caught up now.
I've merged everything up to beta15 now except for:
replaced tr_n with proper snprintf implementation
didn't apply 'tempstring' patch
a few other small exceptions I need to go back and look at.

I must say I'm really impressed with the work. I found very few things in your repo that I disagreed with.

One thing I did see:
Please, don't code rules about specific models into the code (ex DEVO6 or DEVO7e). You should instead define new target_def variables when you need to disable something.

[240] + [30] + [20] + [12] + ... in total will be greater than one buffer [300].

And, once again we will have unexpected reboots with Devo10 and German language.

Actually the tempstring is still one of the things I just wanted more time to think about.
The original plan was to have the strings in the union so that the addition that Vlad was doing doesn't happen. But you can't do that for the dialog, because you don't want to wipe the structure just because a dialog is displayed.
So we already have a big (80*5 = 400) buffer siting there. Using this everywhere should save memory vs the segmented memory and is more stable.

The _tr_n was something I really didn't like, but as I said I understand why you did it, and you didn't have a proper snprintf to use instead.

Also, I definitely wouldn't recommend running my repo in anything other than an emulator at the moment. Doing things like changing the printf routines requires a lot of testing, otherwise obscure bugs may arise. I want to get a conformance test for that code specifically before I'm confident in it.