The midi spec has nothing to do with it. The app has to translate those into internal commands and mappings. There is nothing in the midi spec to define how that is done. Cubase also responds to Eucon for the same control mappings, so that has to be done with either midi or Eucon, and that means it’s translated from either control protocol into internal control commands.
I think you probably nailed the crux of the problem you are seeing though - the CMC custom config is interferring with your generic mapping, and that gets down into a problem with Steinberg’s mapping code for any controller. It’s screwed up for sure, and it’s embedded in Cubase’ assignment approach (and external xml loading), not the midi controller or midi itself.
What irritates me to no end is that this has been in Cubase for a long time, and now it is broken, and has you’ve found, their own controller is handled even worse than most. More than likely, Steinberg is rewriting a lot of core code as they go for some future reason, but this section seems to be half done (actually quite a few seem to be a work in progress).
I don’t know the CMC, but is there a Steinberg CMC driver you could uninstall and try to get it to load as a generic midi device? Might allow it to go undetected as a CMC and let you manually configure it. I’m thinking not since with USB devices, this is likely impossible, but worth a suggestion at least.
(edit) just saw the last post - handshaking is where these controllers get screwed up for general midi use - given what the previous poster is saying, obviously SB is using it’s own mapping to allow button/color feedback (similar to Akai’s APC controller with Ableton - useless for general midi assignments).