mRo Control Zero Classic Pin Mapping Anomaly

Has anyone flown a Control Zero Classic with anything more than 4 outputs?

TL;DR: changing BRD_PWM_OUT on a Control Zero Classic directly affects the number of pins available to motors instead of what is available as GPIO. RCOUT message shown on boot shows the following relationship: RCOUT = BRD_PWM_OUT instead of the traditional {total#pins}-BRD_PWM_OUT.

I’m working on an octo and it seems anything past the first 4 motors receives no response (ESCs do not respond on boot or to motor tests, no signal on oscilloscope) coming out of the box and with confirmed parameters from an old Pixhawk1 (PH1).
I’ve tried both 4.1.3 and 4.1.4beta firmwares (with FRAME_TYPE, _CLASS, and SERVO#_FUNCTIONs set correctly). Repeat on old Pixhawk1 (radiolink & mRo) functions as expected.
On an old PH1, the MAIN motor outputs start on the 7th pin (1-6 are AUX, as seen here). On the Classic, however, SERVO1 is mapped to the 1st pin (AUX1 traditionally).
Increasing BRD_PWM_COUNT increases the number of motors directly by expanding from the AUX1 pin (so, setting to 8 causes AUX1-6, MAIN1-2 to be SERVO1-8 in that order). Additionally, increasing this parameter also increases the RCOUT message displayed on boot on the Classic, though traditionally the relationship is {total#pins}-BRD_PWM_OUT as explained in the above link.

What could be the cause for such a discrepancy? Can the hardware definition be modified to rectify these behaviors? Will my remaining pins still accept alternate GPIO devices (ex. LIDAR), just on the MAIN pins?

P.S: also found that the USB D+ and D- pins are reversed relative to the traditional pinout.