>> The MSVS path seems to be originating from the current directory for a file rather than the start directory. Will see if I find any documentation for 

Perhaps we need the equivalent of -I $(toplevel directory)

I'd eventually like to move away from everything being in one directory (src/core, src/formats, src/filters, etc.) and don't want to have to -I everything.  So I'd like to -I the top level directory and have everything relatively pathed there.

I'm pretty sure we don't have that now.  I just don't want to go further down that road. 
Rounding is just a mess.  I don't have a great solution to that. Chasing sub centimeter location differences across OSes is pretty silly.  Maybe we need a better way to test this stuff.  Ideas welcome.
>> The reasonable for non binary is to round output. For binary formats there is no solution except keeping separate result files... Phew....

You can't imagine how badly I don't want to do that.

Maybe we just say that Cygwin is the only reasonable way to get results that match with testo on Windows.   After all, you need Cygwin to run the shell script anyway, right?

I know this is what results in that alien look I get when I ask the contributor of a new format (that has ^M's at the end of all the lines) for a test case we can slam into testo, but in nearly every case, given a sample file we can round trip it through GPX and get coverage that's usually "good enough".
Didn't we force testo to run in US.UTF-8 pretty much for you in r4525?  Did this not help?
>> Helps for Cygwin, not honored in native Win apps.  I have not looked for a substitute.

Is there a 'setlocale' in Win32?  Maybe we do 
if getenv("GPSBABEL_FREEZE_TIME) setlocale(...
That's kind of an unfortunate way to communicate this to the executable, but that's the hammer we have.