Yes, but I've found that every time the "corrupt pokémon," that I coded simple workarounds for, will save in the key making that slot impossible to break. I've been trying to follow the code to provide a fix, but I still don't know how it happens. I wasn't aware of the issue until I added a box view, where the problem becomes quite apparent. I've been trying to code an option to flush the slot, but having only taken a Java 1 class makes it a little difficult. It would be a "fix" as long as the slot was then seen with two different pokémon and not the one with corrupt data.
More on the corrupt pokémon:
It seems that randomly, before the slot's encryption is broken completely, a pokémon's data will not be able to be read. This usually takes the form of otlanguage being 0, but sometimes moves are replaced with higher than usual numbers. This makes them easy to ignore and not show in dumpPKX_SAV, but I don't know where the pkx file is getting corrupted. On top of that, I don't know how it's getting through verifyCHK as I thought this issue would be a result of bit shift or null areas in the pkx.
However, as soon as the slot is 100%, the pokémon's data is correctly shown, and it causes no further issues within broken slots (obviously as they don't save to the key).
Example:
Like your issue, I've got ONE slot that was filled with a meowstic (with seemingly fine data, but it must be corrupted in an area that is not shown) that will not break, no matter how many pokémon or empty slots are put there. If I put an empty slot there, it will show the ~meowstic, if it's the meowstic it also shows ~meowstic, any other pokémon shows nothing ("Locked Slot"). This one slot is bothersome, but easily ignored because it happened in box 22. I've been trying to flush the data out of the key, but I can't find the appropriate time to do it where it will save to the key.