Thank you sharke, stepD, kev999. Hmmm, okay, I have to do some more digging to find out why it happens here (and with some others) and not for others. (Actually kev999, I thought I first experienced this in 8 or 8.5, but good to test anyway.)

BTW, on my system, Rapture CUT1 depth gets reset to -12000 (it's not really a REset, since it was never at that setting to begin with). Below is a before and an after picture. This is looking like one of those goofy bugs that some users experience, some don't, like the long-standing issue with projects that don't stop playing back. Goofy bugs are the worst.

before playback


after playback stops, dsn't look like a big change, but for some patches it's night and day to the sound

Right-click on that Cut1 Depth 'widget', go to Change MIDI Config, and select Reset.
 
My guess is that the parameter was accidently 'learned' to Rapture's internal MIDI Learn feature.  When you 'zero controllers' with the transport, the MIDI message (like CC1, CC7, CC 11 or CC64) resets the 'bound' parameter to default values.  If you ever right-click (sometimes, shift+right-click) on most Cakewalk synth parameters, it will 'listen' for the next incoming MIDI message until it 'learns' something.
 
All Cakewalk synths with an internal Learn feature have a distinct Midiconfig00.bin file (or Midicfg00.bin).  The number refers to multiple MIDI learn configurations (00-09 in Rapture / LE).  So if you ever get anything flaky happening in Dimension Pro, DropZone, z3ta+, etc., try deleting that associated file first.  It will be regenerated the next (or first) time you use it.  "Change MIDI Config -> Reset" does the same thing.

Well I'll be.....

There are the files, just as you say, b rock:

     Dim pro & Drop Zone use MidiCfg00.bin
     Sound Center, Z3ta+ & Rapture use MidiConfig00.bin
 
     (Looks like Pentagon I uses midic00.rgc?, for those keeping score. z3ta also has a midicfg.txt file.)

My long-standing issue is solved. Two things to add:

1) I'm so-o-o embarrassed. (Now that I know what to look for, I see this issue answered multiple times in the forum--um, all by you, b!)
2) This is not meant to be snarky (though it will sound it, but credit where credit is due), b rock I should have just asked you for a definitive answer first and saved myself (and support) a lot of time. Your knowledge of these things is encyclopedic. (Why doesn't CW have things like this documented for their own staff?)

If you only knew how many times I got "caught" by this in the beginning ... I also reported this as a a bug to Rene Ceballos; long after I should've known better.  Project5 used to blast out 256 MIDI messages [4 iterations of 4 CC / PB resets over 16 MIDI channels] by simply clicking on the interface or transport, with no global setting to defeat it.
 
The advantage (and sometimes the disadvantage) of the internal MIDI Learn system is that it acts across all instances of the synth, and persists through all projects.  Couple that with less-than-full documentation, and it's easy to have something slip in unnoticed.
 
If a user happens to start experimenting with MIDI Learn, or an errant right and left click occurs, it's not immediately apparent that the MIDI routing is going to"stick".  The important thing is that you're now [solved], and maybe that will prevent someone else from tearing their hair out.  Despite the potential for erratic results, I've never been a fan of dumbing-down a synth to prevent that from happening.  I'd rather see more information dispersed where the end users can find it.
 
Here's one hint:  If a parameter is using internal MIDI Learn, you can see it physically move or update when you vary the "bound" MIDI message.  The same result won't happen when you're using the MIDI / Modulation Matrix or external control from your DAW.  The exception might be ACT (which I don't use).