It only took me about two years, but finally identified one more source of midi position errors that creep into projects. 
 
Try this, in a project with at least 2 midi tracks, midi events (notes and controllers) in one of them, and no midi events at time 1:00:00:00.  
 
Select using time range:  1:00:00 to end of project. 
Copy  (CTL-C).  
Move to another midi track.   Set now time to 1:0:0.  Paste. 
 
So far, so good. 
 
Now, select using time range again: 1:00:00 to end of project. 
Cut (CTL-X)
Move to another midi track.  Set now time to 1:0:0.   Paste. 
 
Presto.    Your data is not correctly aligned.   If you watch the 'selection range', as soon as you "CUT", it changes.  
 
You must, with CUT-PASTE, set now time to the beginning of the changed selection range, while with COPY-PASTE, you must set Now time to the beginning of the original selection.    

This is (very) old news if you've been following the discussion about Delete Hole. For whatever reason, SONAR cuts MIDI data starting where cuttable data starts. In your example, when you tell it to cut, it cuts starting where the data starts, not at a place where no data exists. You'll know this because when it cuts, the selection range changes to show that the selection starts where the data starts. Therefore, when you paste at the Now time, where the data starts gets pasted at the Now time.
 
As you've noted, copying is one option. You can then delete the part you wanted to cut. Another option is to place any kind of data where there's no data. For example, if you place a controller node of any kind at the beginning of a project's track, SONAR will recognize that as the start of what you want to cut, because there will be cuttable data.
 

Yet more on selection screwed up by Sonar's idiotic Clip management:   Select the whole project by time, or use CTL-A.    then work down the project in track view, selecting one midi track at a time, modifiying something that matters to you.  If you should come along to a track where the "clip" happens to be shorter than the rest of the project, your selection suddenly changes to be a time range that matches that shorter clip.    Select the next track, thinking you're still working with the entire time range?    Presto:  your modification is only going to to affect the part of that new track's events that lie within the time range of the shorter track.    
This is still another reason for those incredibly mysterious situations, where parts of a project are wildly different than what you thought you had done.    
 
Craig, don't even bother to say, "it's by design".   It's a terrible design, it's a design bug, like all the other crazy selection issues.  

It is working as designed, and you haven't thought through the consequences of changing it to suite your expectation (not mine since I know and like how it works) in one particular situation. Of course selecting a clip sets From and Thru to match that clip's boundaries; if it didn't, you'd be in a world of hurt in a lot of other situations.
 
In the situation described, you need to avoid selecting individual clips; just select track numbers to change track selection without changing the time range.

williamcopper
Craig, don't even bother to say, "it's by design."

 
I didn't have to, Brundlefly has already pointed out why your short-sighted (I prefer to use descriptive terms, rather than pejorative ones like "idiotic") approach would have unwanted consequences in the majority of use cases.
 
Hopefully at some point you will realize that software doesn't learn you, you learn software.

brundlefly
 
In the situation described, you need to avoid selecting individual clips; just select track numbers to change track selection without changing the time range.

Hem.   That IS EXACTLY what I described.   It changes the time range.
 
Edit --- correction:   If you don't change anything in the selection, the time range does not change.   But as soon as you USE the selection for something, and THEN select a track number, THEN the selection changes if and only if the clip in the newly selected track is SHORTER than the clip in the previous selected track.   If the newly selected track has a LONGER clip, there's no change in the selection range.    You say this is as planned?  You must be kidding.
 
Why am I emphatic (other than by nature)?  Because I have lost hundreds of hours of work from exactly these selection bugs.   And I feel quite sure that others have too, just read back through the forums about mysterious changes in midi data that can't be explained.  

williamcopper
Why am I emphatic (other than by nature)?  Because I have lost hundreds of hours of work from exactly these selection bugs.   And I feel quite sure that others have too, just read back through the forums about mysterious changes in midi data that can't be explained.  

 
It sounds like you don't understand the difference between Selection and Focus.

By now, I know pretty well how it works.   Haven't really been hurt for a long time.    The message was intended to help other midi users with less experience, and maybe to hint to the developers that there's still a lot of work to do to make 'focus' and 'select' and 'clip' in different windows work in any kind of logical or even consistent way. 

The OP is correctly reporting a change in the behavior of Cut/Paste that occurred sometime in the Platinum development cycle. 
 
I have attached examples of Copy/Paste vs Cut/Paste in Sonar X3 and Copy/Paste vs Cut/Paste in Sonar Platinum. 
 
If you observe the location of the pasted clip after a cut, you can clearly see that Platinum does not paste at the same location as Sonar X3. 
 
Without being part of the Cakewalk development team, I cannot say that this is a "bug" or "by design".
 
Sonar X3 Copy/Paste followed by undo and then Cut/Paste:

 
Sonar Platinum Copy/Paste followed by undo and then Cut/Paste:

 
Hope this helps,
-- Ron

SquireBum
Without being part of the Cakewalk development team, I cannot say that this is a "bug" or "by design".

That's why I said "for whatever reason," and referenced the Delete Hole discussion. It will be interesting to see how it works after ripple editing is complete.