What is a good workflow for submodule forks

When the developer creates a commit with the submodule at a particular version, that’s a strong statement that the supermodule works with the submodule at that exact version. If his code does actually work with the company’s version of the submodule, I think the right thing to do is for the developer to:

1. branch the supermodule
2. checkout the company version in the submodule
3. update .gitmodules in the supermodule, if the developer changed that from the upstream version
4. stage and commit that change
5. test everything
6. issue the pull request

He can then switch back to his normal development branch in the supermodule.

One thing I don’t understand about your question is the following:

Getting there is not trivial as he needs to replace a submdule with another submodule (to git, the original and the fork of the submodule are two different things).

On the contrary, the submodule can be any git repository so long as it contains the commit which the supermodule points to. If there are two different remote repositories, he can just add an extra remote in the submodule. (The developer should change .gitmodules as well if they’re going to share their repository with anyone else.)

In response to your comment below, perhaps it’s worth going through how to switch a submodule from pointing to one version to another. Let’s suppose that the developer is using their own repositories for the super and submodule, but those are both cloned from the company’s versions (i.e. so most of the history is the same), and the submodule is at the path lib. The developer now wants to switch the submodule to point to the company’s version instead. They can do the following:

1. Edit the url parameter for the submodule in .gitmodules to point to the company’s repository.
2. cd lib
3. git remote add company developer@company:/srv/git/lib.git
4. git fetch company
5. git checkout -b upstream-master company/master
6. cd ..
7. git add .gitmodules lib
8. git commit -m "Switch the lib submodule to point back to the company's version"

Steps 3 to 5 can just be changed to git checkout <whatever> once the remote and branch are set up.