Well there will probably be instances where you'll still need to do what you're doing, but other scenarios where you can simplify your approach. I don't have a panacea, I have a workaround but this thread at least caused me to dig in and find out why I was getting unpredictable results, and the conditions that would produce those results. 
 
The way it's shaping up is there's a "continuum of complexity." There are some projects that work perfectly as expected with a simple clickstream, and others that require a major amount of effort. The goal is to identify which projects don't need the convoluted approaches, and which do.

I admit to feeling a bit concerned/embarrassed when a client asks for a wholesale arrangement edit and I know I have to jump through a few hoops to make it happen without unintended consequences...it sure seems like it should be easier.
As mentioned numerous times, it can't be a single event edit due to all the variables, not the least of which is the practice of locking clips in place ( and often not seeing those) as you do a major section "all tracks" edit. There would have to be boxes to tick on how events are moved on the timeline.
My habit is "save as Test Edit" before executing. If nothing unintended happens, rename to current name. Safety first :)

dcmg
My habit is "save as Test Edit" before executing. If nothing unintended happens, rename to current name. Safety first :)

I honestly feel that most of us have been conditioned to do that as second nature for survival.
 
What really concerns me most are two aspects. First, if you change the OP from "longstanding problem X" to "longstanding problem Y," the thread explodes, a lot of firefighting occurs (possibly including some fixes), and it tapers down. After that it smolders (almost assumed forgotten) until it gets fanned again, then the cycle repeats.
 
Second, and more concerning, is the reaction of truly new users to workarounds that veteran users take as second nature; and then try to force that as "the answer." A new user is not going to be as accepting of an issue that has been outstanding for a decade, especially when it stops creativity dead in its tracks. From a risk management perspective, I always project past into the future and a "decade" is a long friggin' time to wait (for anything); and there is no guarantee any of us will even be alive to use it by then. A new user is going to focus much more on functionality - what exists, and what does not - in some ways it is easier to explain "That has not been included yet" versus "Oh yeah, we have that, but it doesn't work quite right (and hasn't for years now)."

I think another thing to consider is the difference in the ways in which younger and older users perceive software. Those of you who are music production veterans and have perhaps used sequencing software since the 1980's are used to dealing with the limitations of software and are much more accepting of long drawn out workarounds and finicky processes. But for kids who grew up in a more advanced age of software and audio production, who may not even know what a friggin MIDI cable is and are used to using well designed, slick apps that automate everything very smoothly, a long workaround to achieve what in their mind is a very simple operation (delete some time from my song!) is going to make them feel like they're using a 30 year old piece of software instead of a modern, state of the art app.

EDIT; didn't see that mettelus made essentially the same point above.

sharke
I think another thing to consider is the difference in the ways in which younger and older users perceive software. Those of you who are music production veterans and have perhaps used sequencing software since the 1980's are used to dealing with the limitations of software and are much more accepting of long drawn out workarounds and finicky processes. But for kids who grew up in a more advanced age of software and audio production, who may not even know what a friggin MIDI cable is and are used to using well designed, slick apps that automate everything very smoothly, a long workaround to achieve what in their mind is a very simple operation (delete some time from my song!) is going to make them feel like they're using a 30 year old piece of software instead of a modern, state of the art app.

True, but then again, they're probably not inserting time signatures, adding advanced tempo changes, having unquantized MIDI parts, or recording free-form and attempting to line up to a grid later. If they don't introduce those kinds of variables, everything pretty much works as expected. For example I have yet to encounter issues with non-groove clip, audio-only projects.

Anderton

sharke
I think another thing to consider is the difference in the ways in which younger and older users perceive software. Those of you who are music production veterans and have perhaps used sequencing software since the 1980's are used to dealing with the limitations of software and are much more accepting of long drawn out workarounds and finicky processes. But for kids who grew up in a more advanced age of software and audio production, who may not even know what a friggin MIDI cable is and are used to using well designed, slick apps that automate everything very smoothly, a long workaround to achieve what in their mind is a very simple operation (delete some time from my song!) is going to make them feel like they're using a 30 year old piece of software instead of a modern, state of the art app.

True, but then again, they're probably not inserting time signatures, adding advanced tempo changes, having unquantized MIDI parts, or recording free-form and attempting to line up to a grid later. If they don't introduce those kinds of variables, everything pretty much works as expected. For example I have yet to encounter issues with non-groove clip, audio-only projects.

They still have to deal with things like having to insert dummy clips for "delete hole" to work correctly on all tracks and the time range specified. And I think you'd be surprised at how many EDM producers use tempo changes in their tracks, even if it's just a BPM here and there for effect. Besides, I'm of the opinion that if Sonar offers tempo and time sig change functionality then it's edit functions should deal with them correctly - it doesn't make sense to me to leave them out of the equation just because they're only used by a minority. I'm sure the majority of pieces composed in Sibelius or Finale stick to one time signature too, yet they move new time signatures correctly when deleting measures.

sharke
They still have to deal with things like having to insert dummy clips for "delete hole" to work correctly on all tracks and the time range specified. And I think you'd be surprised at how many EDM producers use tempo changes in their tracks, even if it's just a BPM here and there for effect.

 
That's why I said "adding advanced tempo changes." I use tempo changes in most of my EDM material, but it's not as jarring as the tempo changes done in my rock stuff.
 
I'm not saying these issues shouldn't be fixed, just that the more complex a piece, the more variables to deal with when moving large chunks of data, and that I don't think most beginners work at that high a level so wouldn't encounter these kinds of issues as often, if at all.

Anderton

sharke
They still have to deal with things like having to insert dummy clips for "delete hole" to work correctly on all tracks and the time range specified. And I think you'd be surprised at how many EDM producers use tempo changes in their tracks, even if it's just a BPM here and there for effect.

 
That's why I said "adding advanced tempo changes." I use tempo changes in most of my EDM material, but it's not as jarring as the tempo changes done in my rock stuff.
 
I'm not saying these issues shouldn't be fixed, just that the more complex a piece, the more variables to deal with when moving large chunks of data, and that I don't think most beginners work at that high a level so wouldn't encounter these kinds of issues as often, if at all.

That's true, but even a simple tempo or sig change isn't handled as expected, and this desperately needs to be fixed.

sharke
Even a simple tempo or sig change isn't handled as expected...

I'm still trying to wrap my head around this. If there's a gradual upward change over 1 measure, you select three measures with the tempo change in the middle measure, then delete hole (with tempo changes) checked for these three measures, what would you expect to have happen to the tempo map? And would this be what you wanted every time?

Anderton

sharke
Even a simple tempo or sig change isn't handled as expected...

I'm still trying to wrap my head around this. If there's a gradual upward change over 1 measure, you select three measures with the tempo change in the middle measure, then delete hole (with tempo changes) checked for these three measures, what would you expect to have happen to the tempo map? And would this be what you wanted every time?

I think a general philosophy to pursue would be that everything after the deleted region should sound the same as it was before the deletion. So if the last tempo change in the deleted section was 123bpm then that tempo change should be inserted at the point of the cut so that the tempo after the cut is preserved. If this is not what the user wants, they can always remove that tempo event manually.