As a follow-up, I'd check everything in the Clip Inspector actually.  I've had tons of headaches when the "Beats in Clip" was not correct, it would act totally weird when changing tempo.  Maybe an AudioSnap setting is wrong as well.  Not sure if stretching a clip engages AudioSnap for that clip or not.

I don't think it's really feasible to troubleshoot this without seeing the issue firsthand. But in general, I've never seen a tempo change affect anything earlier in the project, so I would guess either you're encountering a bug that's peculiar to this project, or you're inadvertently changing the previous tempo rather than inserting a new one (there's and option for this in the dialog). Since, the M:B:T timeline is the fixed visual reference in SONAR, if you see an audio clip changing length or start time, that's generally prima facie evidence that at tempo change has been made somewhere before the end of the clip. 
 
From what you've described, I think my approach would have been to align the timeline to the existing audio using Set Measure/Beat At Now, and then enable autostretch on all the clips, and massage the tempos in the tempo view to achieve the desired result.
 
Attempting to combine many different approaches as it seems you are doing is bound to get "weird" at some point, especially with many tracks having separate clips and un-bounced crossfades. Setting the Timebase (i.e. start time reference) to Absolute might address the problem, but it's hard to say without seeing exactly what's going on. And, again, it shouldn't matter if the tempo change is being made after the end of the clip.

@rlared
 
Hmm... interesting thoughts about checking the Clip Inspector.
 
Thing is I'm not using Audiosnap for this (yet). The clips are not "Groove Clips" either.
 
I'm just the Slip Stretching the audio to pull in (or out) sections that are lagging (or speeding up) too much.
 
For example... if the downbeat at Measure 10 is on Beat 1 but the section lags over time so that the downbeat that SHOULD be at Measure 20/Beat 1 actually appears at Measure 20/Beat 3 (or somehwere close to it) I create the split at the downbeat and slip stretch the clip back so the downbeat actually lands at Measure 20/Beat 1.
 
Well the downbeat would actually appear in the NEXT clip right after the split so I'm pulling back the spot just before the downbeat. Then I snap the downbeat clip to the measure and create the X-Fade (by slip editing WIThOUT stretching the start of the following clip across the end of the preceding stretched clip ever so slightly).
 
In theory audiosnap or clip tempos shouldn't have anything to do with it. Just the clip(s) getting compressed or expanded and only the split point getting snapped to the timeline (not the transients).
 
That's keeping the human performance. Once I get the overall songs tightened up and the stretched clips bounced I'll use Audiosnap "Merge and Lock" wackiness to make any finite adjustments needed.
 
So maybe Audiosnap IS in play here or something but it still doesn't make much sense why a tempo change completely separate from clips further down the timeline would make clips change size when the Tempo displays are showing no tempo changes have occurred where those clips exist.
 
It's very strange... and that post/description probably sounds strange too. lol
 
Sorry, just typing what's going on.

I agree it's very strange.  For the purpose of keeping things clear, let's call the clips "Pre" and "Post".  Pre is the one that shouldn't be changing but it is. 
 
In the above example, you're splitting the clip at measure 20 bar 3.  Then I believe you're then slip stretching "Pre" so that it ends at bar 19 and then changing the tempo at bar 20.  The only thing I can think of is that perhaps slip stretching is just a "modifier" in Sonar.  So essentially it doesn't edit the clip but just tells Sonar to play it faster or slower.  In this case, Sonar still may think the clip extends into bar 20. 
 
Did you try bouncing it to a new clip after stretching?  That may help.

brundlefly
I don't think it's really feasible to troubleshoot this without seeing the issue firsthand. But in general, I've never seen a tempo change affect anything earlier in the project, so I would guess either you're encountering a bug that's peculiar to this project, or you're inadvertently changing the previous tempo rather than inserting a new one (there's and option for this in the dialog). Since, the M:B:T timeline is the fixed visual reference in SONAR, if you see an audio clip changing length or start time, that's generally prima facie evidence that at tempo change has been made somewhere before the end of the clip. 
 
From what you've described, I think my approach would have been to align the timeline to the existing audio using Set Measure/Beat At Now, and then enable autostretch on all the clips, and massage the tempos in the tempo view to achieve the desired result.
 
Attempting to combine many different approaches as it seems you are doing is bound to get "weird" at some point, especially with many tracks having separate clips and un-bounced crossfades. Setting the Timebase (i.e. start time reference) to Absolute might address the problem, but it's hard to say without seeing exactly what's going on. And, again, it shouldn't matter if the tempo change is being made after the end of the clip.

Hiya, Brundle. Thanks for popping in. Based on your post I think this really could just be project corruption due to so many unbounced stretches. I was really trying to avoid breaking up my bounces and just do a full bounce of everything at the end (the songs aren't long and I'm trying to keep the splits/stretching to a minumum). However I guess I'll try pushing through a third of the tunes at a time (or something like that) with the stretching moves, bounce the work then move on. Not sure exactly how this will look but I guess I can muddle my way into having three or four sections (grouped across the tracks) then flatten or bounce them together once it's done.
 
MAYBE that will keep the project chugging along. And yeah... as I've been wrangling with all this I've been contemplating making a video to show a bunch of the annoying stuff that I'm encountering... however this particular issue definitely seems like an intermittent/project specific thing. At least I hope it is because I'm only on song 2 of this session and I'm starting with the simplest stuff. This simply cannot happen for the longer/weirder songs.
 
As far as the method of setting the tempo/timeline beforehand that's how I originally tried this ages ago (X2 days) then snapping/adjusting around that... unfortunately the music is far too chaotic for such shenanigans. That's why I'm having to "earball" it and micromanage each section.
 
The tunes are 180-200+ bpm and all "punky/metal" with lots of fills and stuff so the prep work to make autostretching happen accurately would take WAY longer than doing it manually the way I am. So I'm just trying to get an overall tempo and smooshing the natural performances into it section by section.
 
The end result is sounding great. It's just getting there that's causing me issues.
 
If tempo changes should NOT be affecting clips earlier in the timeline though I am definitely experiencing bugginess so that confirmation is helpful. It was definitely working the way I want before so hopefully with a little more of a gently touch and bouncing more regularly I can get on with this project.
 
I've got nine of these songs to do and I'm only on track two (and may have to redo track one). Also we recorded two versions of each song so I want to correct BOTH versions to the same timeline in the same project so I can raid drum fills and vocal parts where needed (I am retracking all the guits and probably bass). I haven't even touched the second versions yet. lol
 
Brute force, yo.
 
Thanks again, Brundle.

Set clips and tracks both to absolute time.

rlared
I agree it's very strange.  For the purpose of keeping things clear, let's call the clips "Pre" and "Post".  Pre is the one that shouldn't be changing but it is. 
 
In the above example, you're splitting the clip at measure 20 bar 3.  Then I believe you're then slip stretching "Pre" so that it ends at bar 19 and then changing the tempo at bar 20.  The only thing I can think of is that perhaps slip stretching is just a "modifier" in Sonar.  So essentially it doesn't edit the clip but just tells Sonar to play it faster or slower.  In this case, Sonar still may think the clip extends into bar 20. 
 
Did you try bouncing it to a new clip after stretching?  That may help.

Once I move on to the next song (or maybe the second version of this current song which I will be aligning to the version I'm working on so I can raid for comps) I think I'll try bouncing the stretched clips in sections instead of trying to wait until the end of the song and bouncing all at once.
 
Yes, I do believe that until bounced Sonar is just reading back the stretched files differently so it could be I've overloaded the project with data leading to project corruption.
 
I've also occasionally been getting this MIND TWISTING noise when starting playback like a million sparkle demons invading my ears all at once. It's not loud or anything but it's such a strange and jarring noise that it makes me almost launch my headphones across the room.
 
That to me is indicating some kind of Disk reading problem. I use HDD's (not SSD's) and that has always seem to be the most problematic part of my system so a problem reading back and translating the data could be what's corrupting the project.
 
Just guessing and I'm not smart enough to fully diagnose it.
 
Cheers and thanks.

gswitz
Set clips and tracks both to absolute time.

Thanks, Geoff. I will definitely try this out.
 
Hope you've been well.

Sure.buses can also be set. You can select all clips at once and update them collectively. Tracks must be altered one at a time.

Lastly,I have submitted a feature request to have a single click to alter everything to absolute time.