This is Platinum, Dorchester.    There is a clear difference between 'fast' and 'not fast' bounce.    This is not the same problem as the tempo getting changed, Foxboro issue (maybe).   Seems to me to be limited to ignoring the send from a VSTi output track ('instrument track') to an auxiliary bus.      Works fine with fast bounce off (whether 'audible' or not), and does not work with fast bounce.   Everything else exactly the same.    I think this may be older than Dorchester, I've often felt that bounce results in a different sound than intended. 
 
Edit:   it's looking like a note-off problem, as if Sonar is sending note-off commands on ALL midi tracks for a given VSTI, during freeze and fast bounce, but is NOT sending note-off commands on all midi tracks during playback and slow bounce audible. 

Hmm ... this might be more complicated.    After doing a slow-bounce on the same material, then trying fast bounce again, the aux track effect was present in the bounced material; however one of the notes was abruptly cut off.  
 
Ok trying to track it down further:   tried a "freeze" of the material going to one of the vsti's.    Same note abruptly cut off, in freeze, but sounds normal in regular play.   Using slow bounce, audible, it sounds normal.
 
Further edit: reduced everything to two midi tracks, two notes, one VSTi, two outputs.    Same problem in freeze and fast bounce: the note on one track is cut off by the end of a note on another track.    This does NOT happen, same two notes, same tracks, in slow audible bounce and does not happen in playback.   
 
This is using GPlayer as VST instrument, two outputs.    I tried replacing it with Kontakt 5, two outputs, and the freeze worked correctly.   (However, I believe there have been problems with Kontakt in the past...)     I wonder, now, if the latest Kontakt may be more protective of bad output from Sonar during freeze?   Otherwise, why would GPlayer work one way during freeze and a different way during playback? 
 
 
 

Does this fast cut off happen right on the end of the last note played.  I have seen something similar, it is as if the tail/decay of the sound is cut off because the note has reach it end even though the sound has not reached the end of its natural decay.

My work around has been to add or extend an envelope to the track that extends beyond the end of the track to capture that delay.  Even with the play effects tails on in preferences I have heard this happen.

This likely specific to that synth. Note on's and note offs are matched by SONAR. There was an issue with the counting that was fixed in Dorchester or Cambridge if I remember. 
i.e. if you send 2 note on's for the same note and MIDI channel, the note should NOT stop sounding until the last note off has been sent to the synth. Some synths respect this counting and others do not. So they may stop sounding when they receive the first note off.
You can verify this by making a test track that has a long note and overlap a shorter note (same note number and channel) with that same note on the same track. Check if the synth sustains the original note or cuts it off when the short note ends.

Only skimmed your OP but check the synth documentation for entries on special export settings.
 
Some vsti's experience cut off notes when using "fast" exports and have coded in special settings to correct the issue when needed. I believe BFD is (or used to be) one such instrument.
 
Alternatively you could try just freezing the synth before exporting... if you haven't already tried that.
 
Edit: Was typing that while Noel posted. Seems to be related to what I was trying to say. Check the synth manual.

Thanks for the replies.    It's peculiar.   Still working on it.   May not be related to "note-offs" but rather to memory access allowed to the plugin.   Now I've managed to make the early cut-off come before the other track's note.  ...
 
 
 
 
 

After I did this a number of times, Sonar crashed (I had rolled back to Braintree to see if it made a difference)
 
Problem Event Name:    APPCRASH
  Application Name:    SONARPLT.exe
  Application Version:    21.1.0.38
  Application Timestamp:    54f76a0a
  Fault Module Name:    ntdll.dll
  Fault Module Version:    6.1.7601.18798
  Fault Module Timestamp:    5507b864
  Exception Code:    c0000005
  Exception Offset:    0000000000028fa2
  OS Version:    6.1.7601.2.1.0.256.48
  Locale ID:    1033
  Additional Information 1:    ac05
  Additional Information 2:    ac0507478d1c5bd693cfc4fe3987e900
  Additional Information 3:    80b0
  Additional Information 4:    80b093921c6ccb0b5f40f2203cc7ba41

Downloaded the G-player demo to experiment, but it doesn't seem to have installed DLLs for the 32-bit or 64-bit VSTi anywhere - only the standalone executable. I checked both the non-default VstPlugins paths I gave it, and the paths it defaulted to. Download page says the demo includes the VSTi, so I dunno... Will take another look later.

It is looking like a combination problem, something in GPlayer's 'stacked mode' and something in Sonar.   I'll try to get back to it; have a message into soundlib regarding it, we'll see if they have any ideas.  

Why? Why is it something in Sonar? Why is it ALWAYS something in Sonar?
 
Properly diagnose first before pointing fingers. Did you look into any of the synth settings that may cause the note cut offs? It almost seems like by fixating on this you are making the problem worse. I could never work like that. I'd rather get things quickly sorted in an acceptable way and get the bloody hell on with it.
 
Sorry... it just seems like picking at scabs.
 
BTW... they released an update to Foxboro to solve that Fast Bounce quirk AFAIK. Check your account. Going back to Braintree won't help because after the Bakers look at it they realized it had been there since X3... or so I've read.
 
TMYK
 
*rainbow.gif*