This has been my experience as well writing cross-platform software (some of it proprietary in the past).

Because different compilers and different stdlibs do things in subtlety different ways, that may just work on one platform by chance. Memory alignment/layout is often slightly different for example.

Then IO behaviour is often quite different on Linux and OS X despite both being POSIX... (and once you need high performance or Async IO, you're using native APIs anyway).

Memory behaviour is also quite different in terms of buffering, when memory gets freed, etc - e.g. on Linux you often need some malloc_trim(0) calls to actually release recently-free'd memory), on other platforms that's not as necessary, so there are subtleties there.

Different platforms often have different includes as well (on Linux, you generally use GCC's STL/stdlib, on Windows it's a totally different set).

Particularly around alignment - it could be that your compiler is emitting instructions that can deal with it, but in a sub-optimal way such that there is a performance penalty. On other platforms, that sort of behavior may cause a compilation failure, or the bugs they cause create bigger (and more noticeable) issues.

I understand this. Think more along the lines of "If a tree falls down in a forest, does it make any sound if there is nobody there to hear it?". If there is a defect on Linux, but nobody is running it on Linux, is there really a defect?

It's quite possibly a silent bug on the other platforms as well (i.e. relying on undefined or compiler-defined behaviour that just happens to work currently).

A new compiler / OS update / graphics card driver in the future might trip the bug on the platforms it seems to be working fine on currently.

Lets pretend a few things, because I don't think you understand what I am getting at. I have application called "Music Box", I am release version 2.0.0 and it is QA'd before release against Pear OS 7.0.

If Pear OS 8.0 is release a month later and breaks my application because of an API change their end. I would just release 2.0.1 of Music Box that fixes the defects. If I was proactive get hold of a beta or release candidate of Pear OS 8.0 and QA my application on there to see if there was any obvious defects.

The same with a newer compiler or a newer hardware driver. I would just get hold of the beta / release candidate and fix it then. The one thing I wouldn't do is try compiling it on a completely different OS that none of my users use.