Now that I'm back to a desktop and can dig through a bit of history, I recall the story here.
Naviguide was implemented independently and submitted separately by two different developers (Amit and Erez) in 2009 about a week apart. The Israel Tranverse Mercator/Cassini stuff in Jeeps was added by one of those devs; it wasn't part of Jeeps; it was clearly copy/pasted and beaten into submission. So it's probable that it's "right" for points in Israel, but wrong for points farther from their artificial meridian.
Since _every_ mention of Naviguide on our mailing lists was either during that flurry of activity around checkins or with other, unrelated issues, I can't say that Naviguide - especially with North American data - is really very strategic to us. We've not had a single question about it. That means it either works exceedingly well or that nobody is using it. Roaming around Google doesn't show any blog posts describing how to get your bike ride in or out of Naviguide or such. All of the mentions that I can find of Naviguide (that aren't pirate links) are from the middle of last decade. So my inclination is to say this is a dead format that probably was never actually used by anybody other than the two devs.
It's going to sound condescending and judgemental (Hey, I get to be Linus!) but the reality is that Naviguide picked an internal representation that was specific to one country - http://en.wikipedia.org/wiki/Israeli_Transverse_Mercator
- instead of the extremely common WGS 84, a worldwide standard. This is the equivalent of storing local time in your file formats - of _course_ it's going to work badly for people in other areas. To me, this means that the Naviguide developers simply don't expect that program to be used outside of Israel.
While I think it's awesome that we strive to maintain data fidelity in and out of their program (Thank you, Steve) I can't really hold us to higher standards than the program's own developers. I'm pretty intolerant of making up your own coordinate systems. I can't fake shock that a program that stores data interanlly in an Israeli-centric format doesn't deal with with data in, say, California.
So my grumpy reaction is to say that based on our user traffic that Naviguide in general - and certainly, Naviguide with locations outside of Israel - are not strategic to the health of GPSBabel. I'm totally fine ignoring Naviguide in our contrived torture tests and frankly, it wouldn't take much of a dare for me to suggest removing it completely.
Now, for short answers and history lessons on other issues mentioned.
A) ICS_EN support in jeeps is messy for the reasons mentioned above. It's unfortunate that it's needed at all.
B) I regard Jeeps as one of the best and one of the worst decisions I made in this project. It was abandonware when I decided to use it to fast-forward through the horrible, undocumented Garmin serial protocol of the era. It was also horribly buggy and the code is tortured. But in 2002, there was no way I could afford one of everything that Garmin made (still can't...) and it gave us a big boost onto those devices. I performed rather unnatural acts making jeeps work on USB Garmins and supporting the newer hardware. (Thank Google for funding that work.) Over time, I did indeed identify parts of jeeps that we didn't care about and started compiling them away.
C) C++ is in our short term future. Yes, I know I've been saying that for a long time.
D) The license thing isn't immutable. But I'd rather not revisit it for a bug fix in a function that's never actually executed in the real world on data that actually matters.
E) The Expat situation is unfortunate. I hadn't really realized it before, but since it's been that way for 10+ years, I'm not going to wig out about it, but I'd rather not use it as a reason to do it again. At the geocaching HQ there is a sign that says “Let’s make better mistakes tomorrow.”
With this background, does this test-all case in Naviguide _really_ matter, Steve?