Yeah, this is a really ugly one. I've been bit by it a few times myself.

The real disconnect is in the expectations it sets up: When you view a file and hit "Edit in my Fork", you expect you'll be editing the same file you were just looking at, not a completely different version than the one you clicked the button on.

Ideally it should fast-forward my copy automatically (with audit log about what happened) and load file for edit by hash. As alternative it could probably show how far my master from upstream and provide buttons to manually fast-forward it, or show if there is a conflict. As another alternative the page could allow to select which file to load.

IMHO the simplest solution is to just create a new branch in the fork, with the upstream branch that was just being viewed as its parent, immediately before starting the edit. Then the file can be edited on that new branch. Because the branch containing the file to be edited isn't in the fork, the only clean option is to create one.

Do that, and the save can just automatically go directly to that new branch, without even needing to present any other options. (Maybe the user's given the chance to rename the branch at that point, if they don't want to keep the autogenerated name, but that's all.)

When a user edits a file from their own repo, then the standard choices of "Save directly to $branch" vs. "Create a new branch" make sense, and can be presented.

When working on the command line, I always create new branches from the upstream main branch (which I keep as origin, and leave as the default branch for the clone), then I push them to my own fork with git push -u ferdnyc $branchname. The commits never even make it to my fork's default branch, because I never touch that anyway.

Making a new branch is good solution. I don't think renaming branch is needed at this point. Makes it less confusing for people not familiar with git to make edits online. Less is more.

GitLab has the same editing problem, by the way - https://gitlab.com/gitlab-org/gitlab/-/issues/333898

I wish that surprised me, about GitLab, but sadly it doesn't.

GitHub solved it ages ago, in basically the manner I described. I don't think they actually create the new branch ahead of time, technically, but it's effectively the same thing. They open an editor with the upstream version of the file loaded, and when you save it goes to a new branch automatically named username-patch-N (but editable).