This may require an architectural change to Icom frequency divider logic, as I'd guess that other Icom radios may also be subject to this bug. In my own code for DStarCom, I'm using my expanded table for all D-Star radios that have multiple frequency divider logic, but Chirp supports a much larger range of Icom radios, that I do in DStarCom, so I'd hate for this change to be made universally without a lot of testing on a lot of Icom radios. So, *someone other than me* should decide how/where this should be done. The bug description describes the issue and pretty much everything needed for the fix, once the architectural issue is resolved.
That's fine, I'm happy to do it. I don't know how much has to change architecturally, really, but whatever it is, it needs to be done of course. There is quite a bit of core stuff in CHIRP that comes from the days where all I supported were a few recent Icom models. Thus, drivers for those depend on core lists of things like tuning steps (right or wrong as they may be). So, some separation or care may be needed to avoid breaking indexing into those lists and the like, but again, those are sins that need to be cleaned up anyway.
Unfortunately, my 880 is now mounted (deep) in a vehicle, so it's not easily accessible for general development. However, if I can reproduce this on another model, which I expect I can, then I should be able to fix it and just sit in the car to test.
I targetted it for 0.4.0 so it'll get done.
The ID-31 bug is #771 (today), and a patch has been submitted.
Thanks for the bug, and in advance for figuring out why mercurial doesn't see your change :)