I'm finished with this problem report.   Here's my personal solution:  
 
For midi renders, always use fast bounce with 64-bit engine checked ..  as near as I can tell it is the closest to the original material, and the small time shift comes from not checking that 64 bit option.    If I want to listen, I'll listen after the render, and will never use slow bounce with audible sounds.   
 
The tail problem I'll continue to ignore ... pushing 'play' in between renders with fast bounce seems to clear it out of the bouncing engine's recollection.  

williamcopper
But that is a hell of a lot of work. 
 

No that is not, it is usual work routine.

williamcopper
No, adq, if I did all you specify, sure I'd be a hero.
 

No, you would not, but if you would not do it, you would be ... the opposite.

I don't own kontakt so I inserted the dimpro synth in sonar using a simple guitar patch with a midi A major pentatonic scale. Bounced to track with fast bounce and then with fast bounce and the 64 bit engine enabled. Resulting in two audio tracks. Then I inverted the phase on one track. This resulted in dead silence. 

Willam, here is an excerpt from a Kontakt library manual

MM-Bass randomly chooses between different types of release samples, fret noises and
when to insert pickup-hits. This randomness gives more variation and a more realistic sound.
However, it is also good to be able to predict the behavior to know that your song will sound
exactly the same each time you play it. This is possible by using the B-1 key switch to reset
the instrument. In order to get the same result each time you play back your song insert a
B-1 key switch note in the beginning of the song.
The velocity with which this key switch is played determines the random sequence of values
which controls release samples, fret noises and timing of pickup-hits. You can use any veloc
ity, but please note that if you change the velocity of this initial B-1 key switch note you will
get a completely different sequence of release samples, fret noises and pickup-hits.

 
 

 
When you do your tests, please keep in mind, that instruments may need to be reset first, prior to exporting audio.
 

Thanks, soundwise.   As I said in one or more of the many posts, the instrument used in my tests had no randomization, no key switches, no round robins, no mid controller at that moment, no scripting.   It was a home made instrument from a bunch of wave files; the wave files were part of a commercial package I own, but they were all extracted, tuned, and made mono outside of kontakt and then made part of a kontakt 'group' and that became a kontakt 'instrument'. 
 
Being the obsessive kind of person I am, however, continuing to do new tests.    Taking a much simpler setup, it appears that the different varieties of bounce do line up and do sound and look very similar, though they don't null out in the phase-inversion test.    The 'bounce echo' from the end of one bounce is indeed recorded at the beginning of the next bounce.    And THAT is a plain and simple bug, but it might not be the cause of the original problems.
 
Here's a hypothesis for how sonar might be messing up:   the routing of the target track (using 'Bounce to Track' requires a target track) might in fact affect the result of the bounce, even though the target track is not part of the selected group of tracks being rendered.    All the source routing I had double checked as consistent through out the bouncing, but if you accept "new track" for the target track, it creates its own version of what it thinks you want for routing ... and that was different from what I had assigned in the other target tracks.  
 

I would think the target-track-routing speculation would be easy to test, but it's outside my experience because I never do complicated routing or inserts:    create a target track with an extraordinarily full and complicated routing, certain to introduce a great deal of latency, and render midi to that track. 

williamcopper
Thanks, soundwise.   As I said in one or more of the many posts, the instrument used in my tests had no randomization, no key switches, no round robins, no mid controller at that moment, no scripting.   It was a home made instrument from a bunch of wave files; the wave files were part of a commercial package I own, but they were all extracted, tuned, and made mono outside of kontakt and then made part of a kontakt 'group' and that became a kontakt 'instrument'. 
 
Being the obsessive kind of person I am, however, continuing to do new tests.    Taking a much simpler setup, it appears that the different varieties of bounce do line up and do sound and look very similar, though they don't null out in the phase-inversion test.    The 'bounce echo' from the end of one bounce is indeed recorded at the beginning of the next bounce.    And THAT is a plain and simple bug, but it might not be the cause of the original problems.
 
Here's a hypothesis for how sonar might be messing up:   the routing of the target track (using 'Bounce to Track' requires a target track) might in fact affect the result of the bounce, even though the target track is not part of the selected group of tracks being rendered.    All the source routing I had double checked as consistent through out the bouncing, but if you accept "new track" for the target track, it creates its own version of what it thinks you want for routing ... and that was different from what I had assigned in the other target tracks.  
 

So you've got a reverb or delay on the track which has been mentioned WILL cause variations in the live audio... which is why it needs to be frozen BEFORE the tests. Then they will (should) null.
 
If you had just listened to what was being said and performed the tests as they were laid out instead of arguing, blaming Sonar and trying to convince everyone how awesome and intelligent you are you would have saved yourself AND everyone else a buttload of time.
 
You are in NO way qualified to professionally test this software... so stop pretending you are and get on with making music.
 
Cripes... I'm an uneducated idiot/n00b/hack and even I knew how to test this accurately. I would never DREAM of applying for a paid alpha testing position or suggesting I am capable of filling such a position. If you were in such a position you would have wasted untold man hours/resources arguing your point with the programmers instead of making the slightest effort to understand WHY your tests were failing miserably.
 
I'm sure though you are going to continue to blame Sonar for things you simply do not understand (or do and choose to ignore for teh lulz).
 
I also notice you DID NOT acknowledge that you would at least try to apply the mechanism that Soundwise referred to. Just that you are so wicked awesome that you don't NEED to put proper scientific controls in place to do your tests.
 
Nope. Physics should bend to your will... because... reasons. And if they don't it's Sonar's fault.
 
But at least you, after endless posts, scaled back your experiment to a smaller project so good for you.
 
Based on your results we can conclude that IF you actually disabled the reverb/delay AND properly eliminated any possibility of randomization/variations coming from the synth then Sonar's exports WILL null for you on YOUR system meaning there IS no problem with Sonar export or even your system when not pushed to the point of maxing out your resources.
 
Case closed.
 
You're welcome for my "professional" consultation. I will waive my fee for all services rendered... being the "helpful guy I am".
 
lulz

And here I thought you'd say, Wow!!! You found another one and pin-pointed the cause.     Great work!
 
Not sure why all your rant about reverb in this latest:  I had said earlier there was a reverb and it was possible it would cause some small variation in the sound.     The point here is that the OUTPUT (ie, TARGET)  TRACK and NOT get it NOT the SOURCE TRACK(s) is possibly causing changes in bounce to track.   Why a target track's routing should have anything to do with the bounce, I couldn't tell you.    I'd call it a bug, but if this is in fact the source of discrepancy at least that knowledge can be added to all the other things to know about and be wary of in using this software.  
 
I also don't understand why you keep insisting on Freeze ... that's not part of the issue.   As I've explained at length, though perhaps not perfectly clearly. 
 
I don't guarantee this Target Output Routing is the problem ... as I said I don't do routing work and could easily introduce some new factor into the test.      
 

You are completely mistaken. You do not understand what is going on or how digital audio works.
 
Just stop. Your "issue" has been explained and your claim disproven. Just because you are unwilling to understand the problem or do the proper tests does not mean your arguments are valid.
 
It's over. Go scrounge for your next "bug" to complain about. In the meantime do some research on the differences between analog vs. digital audio.
 
Hint: In the analog world creating EXACT replicas of audio files is impossible due to the nature of the physical world. Check out the concepts of "phasing" and "flanging" and whatever else those topics lead you to.

williamcopper
Thanks for the info, shaking my head at CW ... putting preferences in yet another place ... never occurred to me that the little freeze button on the synth might have its own options.     So, yes, I was doing fast freeze, but the little tidbit there about how the tail is handled might be a great thing to have in the render as 'Bounce to Tracks'.  
 

Seriously you didn't know that freeze had options? Just what and who do you consult about?  This has been in Sonar ever since CW put freeze in Sonar.  Personally I believe Sonar has the best freeze in the industry.