Theoretically Tor Browser's fork is just another development branch of Firefox, just like Mozilla's primary development branch, and they are "uplifting/backporting" individual patches into stable the same way Mozilla might backport crucial dev-branch improvements/bugfixes into stable.
But they aren't landing patches on "stable", but on the upstream development branch (i.e. mozilla-inbound/central). Since it seems more reasonable to view tor browser as a release branch of firefox than as a development branch, it seems like they are using "uplift" in the opposite sense to the normal Mozilla usage i.e. they are taking a patch from a product branch and moving it to a development branch. In that context "upstream" might indeed be a less confusing choice of words.
On the other hand I think it's clear what they actually mean here, so probably not worth worry about too much.
That page doesn't explain the use of "uplift" to mean what's commonly called "upstreaming". That page refers to "uplift" meaning a patch being added to an older Firefox branch ahead of normal whole-branch promotion. (I.e. cherry pickin from the Nightly channel to Aurora, Beta or even Release ahead of Nightly as a whole becoming the new Aurora, etc.)
It looks like this page is designed for people who already know what an "uplift" is, but wish to implement it properly. That being said, it also appears that "uplifts" will include bug fixes made in Tor Browser and sent upstream to Firefox, rather than just features added (but disabled by default) as was implied in the OP article. I would have assumed that bug fixes made in a downstream product would already have a mechanism to find their way to Firefox. Maybe "uplift" was the term all along for that mechanism, or is a rebranding of it?
Uplift to us is bringing the patches into mozilla-central pref'd off so that Tor developers can just pref features on, rather than re-merge patches for each major and dot release. We also add tend to add tests.
Typically landing a patch on a release branch, "uplifting" it from the main development branch (but occasionally uplifting it from thin air into the release branch).
The article describes it as upstream patch that is disabled by default which allow Firefox to be less discriminative when it comes to accepting patches.
It's a mix. Some patches are just getting rebased and landed. For others, the Firefox and Tor Browser teams are working together to re-implement the feature in a way that makes more sense in the broader Firefox architecture.
For example, for First Party Isolation, we took the "origin attributes" feature that we built to support containers (user-specified tracking limitations) and reused it for isolation. In the containers case, origins get tagged with a user-specified label; with First Party Isolation, they get tagged with the top-level origin.
And to be clear, there's no "neutering" going on here. We're adding the full features that Tor Browser has, since the whole point of this exercise is to let Tor Browser user preference changes instead of patches. That means that the full capability of the Tor Browser features are in Firefox if users want to enable them.
Speaking as someone who is familiar with some parts of the Firefox architecture or concepts thereof, but not the source code itself: If you were to implement per-container pref overrides, theoretically yes. AFAIK, prefs are global right now. I don't know if it's feasible to implement this in Fx or if that will leak through to the chrome (process).
But it's an interesting idea! Would you mind filing a bug at bugzilla.mozilla.org?
