I ran into this too, Jackn2mpu. You can reverse it, like you said, but it appears to be tied directly to the Foreground and Background colors you have chosen in the Colors dialog, where selected vs non-selected notes are background/foreground colors, respectively (according to the .ini designation as to which is which). Same goes for the inline PRV in the trackview.
Doesn't look like there is a way to change this, even through a hack of the resources, since the notes we see aren't bitmaps, they are drawn according to the color rules.
I think the Colors dialog, for as complex as it is, needs some overhauling. I don't REALLY think it's that important, but I still like to change things up here and again, and as it is now, you can either use a preset or lightly modified one or one from here on the forums. It takes a pretty deep level of dedication to really do it right, getting all of the elements - and there are a lot.
A few things I'd change:
1. Make the dialog run such that there is a way to select a screen element by clicking on it, which would jump to the color asignment
2. Add a color sampling pen to the dialog so that once you have selected the item to change, you can sample another screen color to get consistency and avoid all the jumping back and forth to other elements to get the codes for the color.
3. Add some amount of skinning rather than the intricate, probably against the rules of the EULA to tinker with, undocumented way we have now, which is to modify the resources directly at the .dll file to change some elements that need to be changed to allow some color schemes to work at all. For example, the background colors of the MSR (and other similar) buttons. They are always grey unless you want to dive into "not easy" territory. Lots of colors look bad with grey.
4. Do something else with where the colors are kept. The registry is not great to deal with. An XML file would be great, and a lot more easily transportable.
Hope this helps. Anyone agree?