Even though CHIRP was displaying 00 - 25 as the initial range, it downloaded in excess of 800 memories (I'm guessing the 800 + 45 special mems), however it did not display all of the memories between 00 and 25 as I would have expected. It displayed 0 - 9 and then 16 - 21, followed by 34 - 37. Everything else was missing, however when I looked at the debug log it had read 845 memories.
Right, that's the idea. It's downloading them in the background if there is nothing else to do. It does this so that it has them cached in case you want to look at, say, 90-100 a few minutes later. In other words, if you're not asking it to do anything else, why shouldn't it be downloading the rest of the radio to have it ready in case you want it?
I then looked at the contents of Mem 10 (on the radio) and it matched Mem 16 in CHIRP, likewise Mem 11 on the radio matched Mem 17 in CHIRP, etc. I checked Mem 22 (on the radio) as the next break in the memory map and it matched Mem 34 on CHIRP.
Okay, I'm not sure I understand. Are you saying that unused memory gaps are resulting in an incorrect ordering in CHIRP?
One other thing I noticed was that even though CHIRP downloaded the entire contents of Band A, without prompting when it was initially connected, if I instructed CHIRP to display 00 - 800, it would download the entire contents again.
Hmm, that's not the way it's supposed to work :)
One thing that may be throwing you off is that it (yet) doesn't cache empty memories, so it will check the radio again to see if those have been added. Is this perhaps what you perceived as re-downloading the memories?
If not, does it do this on Band B? In all honesty, I rarely test with Band A since Band B has more stuff to go wrong, so perhaps I broke something with Band A specifically.
Thanks!