Looks like this scenario is common enough that it deserved a mention in Linux contributor's guide [1].
> On very rare occasion, you may see something completely different: another developer posts a different solution to your problem. At that point, chances are that one of the two patches will not be merged, and “mine was here first” is not considered to be a compelling technical argument. If somebody else’s patch displaces yours and gets into the mainline, there is really only one way to respond: be pleased that your problem got solved and get on with your work. Having one’s work shoved aside in this manner can be hurtful and discouraging, but the community will remember your reaction long after they have forgotten whose patch actually got merged.
> On very rare occasion, you may see something completely different: another developer posts a different solution to your problem. At that point, chances are that one of the two patches will not be merged, and “mine was here first” is not considered to be a compelling technical argument. If somebody else’s patch displaces yours and gets into the mainline, there is really only one way to respond: be pleased that your problem got solved and get on with your work. Having one’s work shoved aside in this manner can be hurtful and discouraging, but the community will remember your reaction long after they have forgotten whose patch actually got merged.
I think that summarises it perfectly.
[1] https://www.kernel.org/doc/html/v4.17/process/6.Followthroug...