For now, I think you are just screwed.
KoLmafia writes its own overrides for some of the files - tradeitems, itemdescs, equipment, statuseffects, modifiers, familiars - if it detects unknown objects of that type when it looks at inventory, the charpane, the terrarium, and so on. When you start up again with the same .jar, it reads those override files. When you start up a newer .jar, it assumes that, perhaps, the override data is incorporated in the new version. If it is not (or if only some of it is), it will write new override files if it detects new objects again.
The way I originally coded this was that we only deleted overrides if you upgraded major versions. Otherwise, we left the override file intact and compared its modification date with that of the file built into the .jar. If the .jar file has a later date, we skip it. You may have seen the message "Skipping stale override" in the CLI at login. That's what's happening. Each data file has a data version number and we also skip an override if it has a different version number than the built-in one.
That worked fine when I compiled the .jar file and KoLmafia wrote the override on my computer. The problem comes when people on other computers, whose system clocks can be arbitrarily off, run the .jar files that I create and upload to sourceforge, or fewyn's server creates and installs on the build server. Your clock is one hour ahead and you run a build immediately after it is uploaded? Your local overrides trump the newer & better files built into the jar, and you submit a bug report claiming that I did not, actually, add such-and-such an item to KoLmafia.
The solution I adopted was to delete overrides with prejudice when you run a newer version of KoLmafia than you did last time.
In spite of that, people STILL have problems and the common advice on the forums is "clear overrides via update clear". I don't understand why. I have never had problems with overrides. Theraze used to have a sushi patch that corrupted override files and people running her version frequently complained that overrides didn't work, but I spent a fair amount of effort making sure that that KoLmafia wouldn't write corrupt override files even in the presence of (what I think of as) corrupt data in the internal tables, and I've heard no issues since then.
One possibility would be to not actually write overrides when we detect new items, but simply enter the objects in the various tables so you can use them in-session, much as I did recently with unknown monsters. Then, provide a special command to dump the internal tables into override files, if that's what you want to do. That way, the only override files you will have will be ones you intentionally create, either by hand or with the special command. We will re-detect new objects every time you log in and re-enter them into the tables, but, that's not really especially time consuming.
That really wouldn't be too hard: just removing the call to "writeDataOverrides" (or whatever it is) from the new object detection code and call it only from an "update override" command or something. Plus remove the code to delete "stale" overrides.
