I just noticed that hitting 'PAUSE' on the tranport bar (or 'PLAY' during play on my VS100) no longer advances the STOP marker to the now time cursor.  And 'STOP' only advances the STOP marker if 'On Stop, rewind to now marker' is NOT checked in Options.  So we now have a true PAUSE in Sonar:  PLAY starts playback.  PAUSE interrupts it;  PLAY resumes from the PAUSE  point; and STOP takes you back to where you were last stopped. Great!  I contributed to a thread asking for this function - familiar to all old-time tape ops, right? - and I am so happy to have it.  Is it new in Kingston or did I miss something?  Or am I on the wrong planet?  Or still dreaming?  Thanks, anyway!  PS...  So shouldn't it be called the STOP marker rather than the NOW marker?

It works as expected on my Mackie Control. 

You can invert this in Preferences IIRC.
 

The bug was introduced with X3 and fixed in Kingston.
http://forum.cakewalk.com/Pause-doesnt-pause-it-does-Stop-with-Now-Marker-CWBRN23593-confirmed-by-CW-m2978030.aspx
 

It still doesn't work as expected if you don't have On Stop Rewind enabled, however. The Now Marker should always stay put during playback, and the setting of On Stop (or the use of Ctrl+Spacebar) determines whether the Now Cursor rewinds, or the Now Marker jumps forward to the Now Cursor on stop.
 
Currently the Now Marker travels with the Now Cursor when On Stop Rewind isn't enabled such that Pause and Stop are the same, and you can't rewind on command to some marked starting point other than zero. The last time every combination and permutation of Pause, Stop, Rewind and On Stop Rewind worked as expected was 8.5. I just got in the habit of using a loop to set an alternate Rewind point.
 
 

brundlefly
The last time every combination and permutation of Pause, Stop, Rewind and On Stop Rewind worked as expected was 8.5.

 
Maybe the function that you think still doesn't work as expected was removed in X1?
Is it still documented in the 2015 reference guide?

RE. Brundlefly's post.  Oh yes.  I see.  When I use the on-screen transport bar with 'Options, on stop rewind to now marker' UNCHECKED, the NOW marker advances with the NOW cursor (the vertical white solid line).  There is no difference between STOP and PAUSE.
BUT if 'stop on rewind' is checked, the NOW marker stays put at the start point.  The start and pause buttons on screen alternate between blue and light grey.  It actually doesent matter which you click, they are just the reverse of each other: in PLAY, play is blue;  in PAUSE, pause is blue.  In PLAY, the stop button is light grey -active- but once you PAUSE it's greyed out - inactive.  So there's apparently no way to activate STOP and go back to the START point, no true pause.
 
But there is for me!:  my VS100 STOP button still works during pause, and pressing it jumps me back to the NOW marker.  This is weird:  the VS100 has no PAUSE button, I just press PLAY alternately for play and pause (it's solid green on play, flashing on pause).  But STOP must be sending some other MIDI data to Sonar because it jumps right back to the NOW marker (though with a horrible audio glitch ?? why?). 
 
If, like me, you use Sonar mainly for audio and frequently need to audition passages in detail, a true PAUSE is invaluable, and now I've got it back via VS100.  But not the transport bar.  I don't have the time/expertise/equipment to work out why this works for me this way.  But I hope someone can figure it out and post it as a feature request for everyone.  PS. Thanks to all you great forum helpers, no other DAW has all this!

icontakt

brundlefly
The last time every combination and permutation of Pause, Stop, Rewind and On Stop Rewind worked as expected was 8.5.

 
Maybe the function that you think still doesn't work as expected was removed in X1?
Is it still documented in the 2015 reference guide?

The simplest example that the behavior is not as intended per the current Ref. Guide is this from page 269:
 
"You can change the Now time marker behavior so that the marker moves to the current Now time when playback
or recording is stopped (on the Track view Options menu, clear the On Stop, Rewind to Now Marker option or
press CTRL+W)."
 
The above implies that Now time should not move with the Now time during playback when On Stop, Rewind is disabled, but it does; there's no need for the marker to move to the current Now time on Stop, because it's already there.
 
8.5 is consistent with the 2015 Ref. Guide. X1, X2 and X3 all differed slightly from each other, and I don't believe any of them were fully consistent with their respective Ref. Guides. X2 was very close to being right again, but when you hit Rewind after pausing, the Now marker would jump back to Zero as the Now time jumped back to where the Now Marker had been and should have stayed. So Rewind to a non-zero starting point after Pause would only work correctly once.
 
 
 
 
 
 
 
 

I defer to your evidently deeper knowledge of this issue than mine.  But I've been using Cakewalk since Pro Audio and I too believe this is an anomaly that has crept in somehow.  My projects are now littered with temporary markers -the VS100 is great in having an 'add marker' button- and I have 2 function keys assigned to 'jump to next marker' and 'jump to last marker' as clunky workarounds. 
 
But it's still a glitch, not really a feature request we have here:  how come 'STOP' is greyed out and disabled in the on-screen transport when 'PAUSE' is engaged but no equivalent MIDI sysex message is generated to my VS100 control surface to mirror this event?  I am glad, mind, as it helps my workflow that my hardware STOP button stays illuminated and works as expected, even though my on-screen transport bar button doesn't.  And I think something HAS changed in Kingston, but I'm not re-winding my system to check in case I lose it!
 
I wonder if any other control surface users have any similar experience/comment/analysis?  I know thw VS100 is a legacy Roland unit now, but it was a factory product when I bought it back when Roland owned Cakewalk.  And it still works great, no one's having mine!
 
Come on, bakers, this isn't a biggie, surely?  And workflow is so vital, and transport is the absolute centre of the workflow universe!
 
PS. As I rarely post and it's now December, Happy Peaceful Christmas everyone! 

Likewise, I will have to defer to your greater familiarity with the VS100. My control surface for transport controls is the PC keyboard. syncing control surface status to the application is a whole other pail o' worms that I'd rather not have to contemplate.