A better option would be to remove the SetPoint right there instead of clearing the points later. And I commited a change to do just that just now.

I do wonder though, this problem seems to only occur if you create the widget but then don't do anything with it. Even if I just create it and then add it to a hidden and otherwise untouched container, it never shows up, because the container takes over its handling.

So this means that any addon using it through AceConfigDialog didn't seem to ever trip into this problem. Not that I've noticed either way.

Ace3 does no such thing. The AceDB code handling profiles is quite simple and proven, the only time it touches profiles of characters other then the one you are currently on is when you delete a profile (it switches everyone that uses it to the default profile), otherwise it only ever touches the profile entry for your current character.

Note that SVs getting re-ordered is normal and just how Blizzard saves them.

AceGUI frames or widgets are not meant to be "normal" frames, you access them through the AceGUI API, not anything else.

If you want a frame in full control, create your own and either implement the AceGUI container API, or just shove a invisible "SimpleGroup" into it to serve as your main container, or a ScrollFrame container if you need scrolling.

That also shouldn't work. You are not allowed to overwrite the tables directly in self.db, as these are the special root tables and hold a bit of magic.

If you want to exchange the entire contents of the self.db.char table (or any self.db.* table), you need to delete its contents manually and then merge the existing table in.

The reason for this is that "self.db" itself is not actually something that is persisted in the SV. It just holds references to the individual tables which are persisted in the SV (with appropriate redirections for the context-sensitive storage areas) - if you overwrite that reference, then its no longer saved.

If, for some reason, you push a bunch of tags, the new packager will only package the latest 10 by date in the repository. Of course, just like the current packager, you could just turn off packaging before pushing and then turn it back on.

Unfortunately, that still confused the old packager.
Once you turn packaging back on, it would get into its usual scheme of building broken old packages all the time.