I think that this should be fixed by adding configuration for it (though not exactly as proposed in the title, see below ), in the name of user freedom and customizability, as well as to promote the usage of, rather than hinder, the still-emerging, welcome
prefers-color-scheme standard. As mentioned, RFP itself exists to enforce user choice and freedom in the first place (well, in more ways than one). Explicitly, in enabling or disabling RFP, the user is already choosing between tradeoffs, which is why it's not forced to be on for everyone. Yes, changing your "public-facing color scheme" from the RFP-default could act as a vector to lower your fingerprinting resistance. I won't repeat points already made. Let the user choose. And allow the user to be able to make a better choice than "either break site dark theming and color consistency across browser and potentially burn my eyes, or completely disable RFP altogether".
 I feel this should be handled by a new pref under
privacy.resistFingerprinting.* that dictates the exposed
prefers-color-scheme value in contexts in which RFP is currently active. For example, a string
privacy.resistFingerprinting.announced-color-scheme (or whatever other name) that can be set either to directly 'outbound' values ("no-preference", "light", "dark", possible future additions) which always forces that output to websites, or to a special other value (e.g. "auto" or "default" or a more unique word/symbol/string) that causes the normal current preferred color scheme to fall through to websites, i.e. with this value Firefox will fall back to broadcast same value as it would have if RFP was off. To maintain the current behavior, this new pref
privacy.resistFingerprinting.announced-color-scheme would have the default value of "light", though giving it the 'auto' value by default instead might be better overall, especially if it can be assumed that dark mode users are not as rare among RFP users; this will make the default RFP profile be more diverse in color-scheme vector and may lead to normalizing the 'RFP resistance hit' among light- and dark-color-scheme users so dark users don't stand out as much after all, with perhaps practically only net benefits. An idea to consider. You could also make this pref a little simpler but less flexible by making it a boolean instead, where one value leaks the user's browser color scheme and the other spoofs it to a hardcoded "light" value like right now.
Adding this new pref is more robust and stays consistent with the direction of "turning on RFP takes precedent over all other settings" (except
privacy.resistFingerprinting.* sub-settings) as well. There are already other
privacy.resistFingerprinting.* prefs that allow tweaking observable RFP behavior and thus altering or narrowing the fingerprint, so it'd be nothing new there.
This is part of metabugs https://bugzilla.mozilla.org/show_bug.cgi?id=1401440 and of course https://bugzilla.mozilla.org/show_bug.cgi?id=565512. Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1450398.
Only mentioning this since I'm suffering from it this very moment - funnily enough, having RFP on "breaks" this very site in the current state of things, as a manual dark theme toggle here doesn't seem to exist as on other sites (or I can't find it), so I'm fatiguing my eyes writing this at night on an otherwise dark browser and OS.