I'm trying to wrap my head around how this all would work. Hopefully you can help walk me through it a bit.
So at the moment, there are a number of places where prefs can be set to affect wpt tests:
- WPT test manifests (like ).
- The unittest-features profile user.js, and the other profiles that get applied  for web-platform-tests.
- I think whatever comes out of all.js for the current build get applied? There's #ifdefs for EARLY_BETA_OR_EARLIER and NIGHTLY_BUILD that can affect the set of prefs used, among others.
If I understand things correctly, the priority of those preferences goes 3, 2, 1.
With the proposed changes in this bug, we would be swapping out  for a different set of preferences (web-platform-tests-stable) based on the release channel, right? Or just not including unittest-features, but leave the others?
Where is that other set of preferences being defined? It would very quickly fall out of date if it's a hardcoded list of prefs that needs someone to manually update.
Can we instead just ignore the unittest-features profile on non-mozilla-central builds and let all.js handle the list of prefs we use?
None of this prevents prefs set in wpt manifests from overriding these preferences, and wpt tests really should be setting dependent prefs in their manifests, so I'm not sure how we can run tests against a set of "stable" Firefox prefs for release without adding additional complexity to test manifests to say something like "don't set this pref if run against release" or "expect this test to fail on release builds".
(As an aside, I wonder how many prefs in https://searchfox.org/mozilla-central/source/testing/profiles/web-platform/user.js should be folded into the unittest-stability profile?)