The problem applies to both playback and rendering   --  the most recent problem I had was working on a passage deep in a piece, and getting it entirely correct by ear, and then doing a render from the beginning -- the controller values and patch changes DID appear in the full render but HAD NOT appeared in the lengthy work -- so I was mixing based on incorrect look-back. 

Further -- Brundlefly, I have no idea if you are simply volunteering here, or representing CW -- but take what you said above:
 
Call it a bug if you wish, but bouncing was never intended to include events that aren't selected.
 
Now, imagine using an "Audible (slow) Bounce" --- do you think that look-back should not be used in this case?  Of course not -- look-back is and must be part of playback and of rendering.  
 

As I said, you'll need to give a recipe for a problem on playback. I can't reproduce that.
 
Incidentally synth recording (you'll need to update, of course) works around the rendering limitation because searchback works at recording as well as playback.

I really wish people would never post that way, dismissing and misdirecting.   Your comment makes it look like I haven't given a formula, but if you look up three comments or so it's there plain as day.   It applies to render and playback.   Can't be more clear than that.

I don't work for Cakewalk; all my contributions here are voluntary. It's not that I don't think searchback should not apply to rendering. But keeping in mind that this feature pre-dates soft synths, it's clear to me that it was simply never extended to include rendering VSTi output for events that aren't selected. Code for new functionality doesn't create itself.
 
 
 

williamcopper
I really wish people would never post that way, dismissing and misdirecting.   Your comment makes it look like I haven't given a formula, but if you look up three comments or so it's there plain as day.   It applies to render and playback.   Can't be more clear than that.

Your "formula" was very unclear. You never said you were bouncing a limited selection that didn't include the controller until after I figured it out myself. And you said searchback "doesn't work". I'm telling you it works for me on playback (and recording), no matter how far back the controller is. That's not misdirection; it's just a statement of fact of what I'm seeing.
 
Over and out.

Glad to hear your responses are not official.
 
Please satisfy yourself that in fact look-back IS CURRENTLY IN USE, ALWAYS.   For any kind of rendering. 
 
And then maybe satisfy yourself that look-back fails with duration.  
 
I'm working on a sample project now to illustrate ... give me a few.   I'm usually reluctant to start a new project when I'm working on an old project, because of the way Sonar changes preferences secretly and unpredictably ... so I'm having to make a copy and delete everything but a note and a controller change. 

williamcopper
Please satisfy yourself that in fact look-back IS CURRENTLY IN USE, ALWAYS.   For any kind of rendering. 

Okay one last response:
 
Please satisfy yourself that the Ref. Guide makes no mention of Searchback applying to offline rendering. It's a playback function.

Ok, tests unsuccessful with single notes, single controller change, and simple duration --- maybe in fact it is track item count that is causing lookback failure -- all my tracks are quite full with notes and pitch changes and controller changes, and the bug is absolutely real in real projects.   
 
edit -- To your last (re the Ref Guide) ... someone must not have noticed how the software works.   Look-back is always in play.   It would be impossible to render midi otherwise, other than entire track at a time. 
 

Doubtful, but...  any chance the difference between your two results could be the version of SONAR used?