PLease file a bug.

“Please stop stepping on other plugins’ logic.”

I agree, if and only if the aircraft plugin does its best to use the default datarefs and commands!

Xsaitekpanels, XHSI and other hardware and software cockpit component builders have the same problem: custom aircraft plugin logic that is separate from default logic, without any attempt of fallback.
I have seen a case for example where the navigation display map range selector in the virtual cockpit changes the default dataref, but not the other way round. All external hardware or software navigation display map range switches will be inoperative.
Another example is the flight plan of the custom FMC not being copied to the default FMS flight plan, even not a simplified copy.

If the CRJ200 has its own logic for the avionics power, then it is OK to ignore the position of the dataref for the switch, as long as the dataref for the actual presence of avionics power is correctly updated.

Cockpit builders are clearly a target for X-Plane, so the aircraft authors would do well to do that too…

Specific _commands_ to actuate the left and right brakes are gone in v11. Instead we auto-toe-brake with rudder/tiller IF you don’t have hardware brakes.

DATAREF access to the brakes will come back before we go final, but with the caveat that plugins that want to control the toe brakes will need to set an override in v11 (as opposed to v10). This is needed to hand over toe brake authority from x-plane to the plugin.

If you were able to assign a toe brake axis using x-plane’s built in mechanism in v11 until now, please file a bug.
If you are using a third party add-on for toe brakes, that add-on will need to be updated, and cannot be updated until we address the brake datarefs.

I’m hoping to have the brake datarefs sorted out in the next beta.

That is not possible because X-Plane doesn’t know whether the 3d model contains a polygon that happens to be tied to a certain switch dataref.

AFAIR left and right brake were removed in beta 10 or 11 (and didn’t come back up to beta 13 it seems).

This won’t help in this case, because avionics_EQ will read “1” in the CRJ, so devices can be powered down. But the plane plugin gets to decide whether stuff is powered up or down, not a non-existing hardware switch. Please stop stepping on other plugins’ logic.

If the sticks wouldn’t center, would we need trim then? I guess yes, because trim also extends the range of control.