Good catch on the times, but they're only out of sync temporarily because I scrolled the view in the PRV later. And the seemingly incorrect controller view was created by deliberate manipulation; there's nothing buggy about how it got to look that way. I just wanted to demonstrate that GUI snapshots are meaningless without knowing the steps that get you there.

The only steps I have found that can reproduce the OP's problem involve using Bounce to Clip with a MIDI Track channel that doesn't match the channel in the clip, which forces a channel change on the MIDI data in the clip(s).
 
I believe the forced channel change is working as designed and gives the expected results, since it has existed since at least Sonar 8.5 (earliest version I could confirm on my system).
 
I agree that the MIDI data lane behavior could be improved to not persist the previous channel's lanes, but until someone logs a problem report the OP's problem could be avoided with some basic housekeeping and workflow modifications:
 
1.  Set MIDI track channel to match the channel of the track's clip data before editing

Doing this will prevent the "surprise" channel change that occurs with a channel mis-match when using Bounce to Clip.
 
2. When intentionally forcing a channel change on a track using Bounce to Clip, close and re-open any open PRV window that is associated with the track.
The MIDI data lanes automatically refresh when the PRV window re-opens and displays only the CC's from the current channel.
 
EDIT: 
3.  Set MIDI track channel to "None" before editing  (credit to bvideo in http://forum.cakewalk.com/FindPost/3200873)
This will prevent the MIDI channel from being modified on the existing Notes and CC's when using Bounce to Clip.
 
Ron