Initially I had to face this choice, and I decided to go for the independent fork for a couple of reasons:
1) As you said, my guess was that the core part would diverge dramatically, if not for the separated files that can be kept in sync anyway, like event loop, string library, and so forth. And the time is showing this assumption was true. The code is diverging and as it diverges the effort to take it under the same library may become complex.
2) This was even important than "1": the effort to rewrite Redis in terms of a common core was a big one. I was not able to stop the development to undertake this effort, just for a side project which was not clear at the time where was headed. Now I'm more confident that Disque will get my attentions for the next years, but still I don't have the time to attempt such a big refactoring / rewrite.
However I cherry-pick from the common parts, and do some "diff" from time to time to see if there are ideas in one side that can be merged in the other side. Is not optimal, but I had no choices. What can be done in the future is to turn more parts of both systems into common libraries that can live in separated files, and rewrite only those parts, incrementally.
Do you think because of their different guarantees that shared code will diverge?
Do you think that base layer will have to be kept in sync? (bug fixes, improvements)
I guess I'm asking, if at all, at what point would you pull that skeleton out into a separate repo and share it across Redis and Disque?