Whats the real problem?
VFP (no idea how far back but possible Fox as well) uses the BGR numbers for colors. For convinience RGB() was added, but not a single line states that the return of RGB() is in any order. Thats (your) pure assumption.
Help says: Returns a single color value from a set of red, green, and blue color components. and The value returned by RGB( ) can be used to set color properties such as BackColor and ForeColor.
Where do you see a something that gives an order or a construction rule?

If you look into the examples given by, lets say HELP BACKCOLOR, you will see the numbers as they are.

There is no excaption for the use of the color value anywhere in VFP, so there is no problem too.

If you need an explanation learn about byte order aka endianness. There is some C that runs the VFP code and in the days of yore a developer has decided to use it in that order. While it is no issue to a VFP developer to concenate the number the one or the other way, it might have been a big deal to rework every number sometimes. But possibly M$ decides to change it in the next version. :)

>if the decimal number returned by RGB() is using the parameters in backwards order, that is a major bug that contradicts all the VFP docs and common sense. It also is internally contradictory. Using the RGB() function to set a color property works exactly as the docs say and as one would assume - R then G then B. But the RGB() functon returns a completely different number when used not to set a property but as a function to return a value.
>
>IOW .backcolor=rgb(204,198,149) shows the correct color. And it returns the correct value. But the function RGB() when used by itself returns a number based on backwards BGR order. That is beyond inexplicable. VFP is really using BGR but internally converts everything in a color property to RGB?