Samples should be the same regardless of the software being used. The problem arises when you have multiple samples playing at the same time and the sample timing accuracy is off by variable amounts. If the "timing shift" is uniform across all tracks it's not really an issue. But if one track seems to be 7 samples longer after a couple of bars, and another isn't, this could theoretically cause issues. I realize these are very very small deviations, and I definitely would not be able to pick this up as a fault. But when we're talking stacking frequencies, phase aligning, loudness maximizing, inter-sample peaks etc., this can become an issue.
 
Hence, I'm interested in what the engineers have to say. There could be an entirely logical explanation.

this seems to be a looping artifact  in sonar.  
the basic way that i tested the idea was setting up a project with the 122 and 140 bpms and pulling in a loop, 
dragging it to bar 95 and bouncing.  
if you take a look in the media browser, you can click on a loop and see its number of samples, which changes on load and tempo and sample rate and then whether you loop or unloop it.  
i think that there is an inherent difference between the way reason, cubase and studio one handle "loops" - they basically make repeated copies of the data, which is a bit different from sonar's method.  
what i think is happening is as was suggested above - the clock ticks are dropping 7 samples - because if you look at the clip in m:b:t time reference it shows a length of 375:959.  
if it was dropping 7 samples per bar i think it would be an issue.
i'm having flashbacks of looking at this about 3 years ago...

Somehow I knew I was going to cave and chime in when I first saw this thread...
 
A great way to spin up engineers is simple, and applies here (others have already referred to this in the thread)... when you conduct a measurement, there is always an associated measurement error (+/- X), which is based on whatever ruler is used. As you combine measurements, you get a stack tolerance (combined +/- value).
 
Interestingly, measurement error is taught at a VERY junior level, but when I ask senior engineers "What is your stack tolerance?" No answer. Many engineering issues are associated with this.
 
Always consider the error of your rulers in any precision measurement. This application is engineering, not simply math.

It looks to me that for your tempo of 140 Sonar might be actually using ~140.000158, based on my calculations.
 
Depending on the tempo entered at 12:01:000, I get sample counts of varying "correctness" at 95:01:000 (and beyond). For instance, if I put in a tempo of 146, I get a "perfect" answer according to the calculated value.
140.000158

Your total sample count is off by about 1 ppm (part per million). This is about 2.5 seconds per month. Most quartz timepieces are not this good. It might be a little better if you used a high-priced master clock, which claim to be sample accurate over 5-10 minutes. Probably best to take a pass on this problem. 

is this inevitable rounding /approximation in the code cumulative? if I do more processing do I become more approximate?

swamptooth
this seems to be a looping artifact  in sonar.  
the basic way that i tested the idea was setting up a project with the 122 and 140 bpms and pulling in a loop, 
dragging it to bar 95 and bouncing.  
if you take a look in the media browser, you can click on a loop and see its number of samples, which changes on load and tempo and sample rate and then whether you loop or unloop it.  
i think that there is an inherent difference between the way reason, cubase and studio one handle "loops" - they basically make repeated copies of the data, which is a bit different from sonar's method.  
what i think is happening is as was suggested above - the clock ticks are dropping 7 samples - because if you look at the clip in m:b:t time reference it shows a length of 375:959.  
if it was dropping 7 samples per bar i think it would be an issue.
i'm having flashbacks of looking at this about 3 years ago...

When you do a Groove Clip in Cakewalk and extend it to multiple copies, do they actually re-sample with interpolation for each subsequent copy, in order to maintain a constant clock rate? It would be rare that a clip would be an exact integral multiple of the basic sample period...correct? Or does Cakewalk merely treat the bpm input value as a suggestion and then adjust so that each measure has an exact number of samples without jitter of the position of the first sample? 
 
How, exactly, do cubase and studio handle this? Do they just accept the jitter from measure to measure, and eat the phase issues that are introduced?

Sanderxpander
Samples should be the same regardless of the software being used. The problem arises when you have multiple samples playing at the same time and the sample timing accuracy is off by variable amounts. If the "timing shift" is uniform across all tracks it's not really an issue. But if one track seems to be 7 samples longer after a couple of bars, and another isn't, this could theoretically cause issues. I realize these are very very small deviations, and I definitely would not be able to pick this up as a fault. But when we're talking stacking frequencies, phase aligning, loudness maximizing, inter-sample peaks etc., this can become an issue.
 
Hence, I'm interested in what the engineers have to say. There could be an entirely logical explanation.

At 20kHz, 1 ppm is 8 degrees of phase shift...probably negligible

Where  are the engineers andrew mentioned?

Did a little more testing with an empty project with an empty midi track:
 
If I take a tempo of 140 (or whatever) and don't bother with tempo changes, and look at a much higher measure#, something like 1000 or more, I find that the time in milliseconds matches the calculated time for the number of samples, not the number of measures/beats/tics. If I calculate the tempo from the sample count @44.1kHz over a long period of time, I can predict correctly the sample count and time in ms.
 
This again leads me to believe the sample count is accurate, but the tempo is not exactly what it appears to be set to. And since the time displayed matches the sample count assuming 44.1kHz, it implies to me that it is not a clock timing issue.