Proton is not exactly a fork. I prefer to call it a friendly downstream distributed with a lot of other software (vkd3d-proton, dxvk, gstreamer). People working on Proton's Wine are primarily considered upstream Wine developers and are expected to upstream everything they work on if applicable.

To answer your questions:

1. We rebase Proton patches on top of upstream Wine when a new major version is released (e.g. 8.0, 9.0) or when porting commits between upstream and our downstream (think cherry-picks) is getting too annoying due to the delta. That leads to a creation of a new branch. proton_9.0 is based on wine-9.0. Other commits are cherry-picked from upstream whenever applicable (e.g. we know they fix something important for us, quite often those are developed because of Proton, upstreamed first and then cherry-picked).
2. proton_9.0 contains a lot of downstream patches. That's everything that's custom to Steam environment (steamapi handling, registry entries), features that are not upstream (fshack that does scaling, pillar- and letter-boxing avoiding modesets) or game specific hacks. Quite often patches first end up in experimental_9.0 and then get promoted to "stable" once they've matured and we haven't heard about any regressions.
3. It's moderately painful due to sheer volume of patches. It motivates folks to upstream their changes if possible. There's a lot of people involved in the process. Usually everyone working on Proton rebases patches in their area of expertise. It's a huge collaborative effort where we maintain a list of downstream patches and then slowly chop away at it, either via removing patches (upstremed / fixed by unralated upstream change) or rebasing. Sometimes features require almost complete rewrite due to the size of the delta.

Cheers!

Thank you for the very detailed response!

I've got a follow-up question regarding #3 if I may:

It sounds like you have a similar approach to the Tor Project who periodically rebase on Firefox ESR. They notably use fixup commits when they encounter conflicts, which does preserve the context for a change but does mean git history loses some permanence. Do you do the same, and if not is there a particular alternative approach you take instead for conflicts and merging?

We don't do merges. We reapply the commits on the new tree. If we pick a patch from upstream we git cherry-pick -x it to include the original commit, e.g. cdd03370324d4a2ae9b3ec95ec3f7752dfb85774. Sometimes that may need a bit of massage to make it apply but that's fine. We may drop a note or revert the commit that created the conflict, apply the cherry-pick and reapply (redo?) the problematic conflict.

We use fixup commits but in a different way - to fixup downstream commits, e.g.: https://github.com/ValveSoftware/wine/commit/f5c2fd9cb7dc27c8c7ea2925a8b45bf4e929988f fixes a downstream hack targeting a game.

It will eventually get squashed into the original commit using git rebase --autosquash. If it's on the proton_9.0 branch the squash will happen when we are rebasing things onto the new upstream base. experimental_9.0 branch is a bit more volatile - we rebase it on top of proton_9.0 whenever a new stable version is released. So next one will be when Proton 9.0-1 is released. We may occasionally rebase experimental outside of this schedule - when it's significantly easier than the alternative, e.g. a bunch of reverts and cherry-picks, there are too many fixups and things get confusing, etc.

To compare two branches that contain rebased version of the same patches I use git range-diff which is an awesome tool.

Very interesting stuff, thank you I learned a lot! Have seen downstreams of a few other projects become unable to efficiently rectify conflicts with upstream and eventually hard fork because of that, and I wanted to avoid that scenario so this was really helpful :)