From reading the scummvm forum discussion it seems like the idea has largely been abandoned.
The problem for scummvm is that they want a stable and *static* codebase to support. Since AGS is still kind of in development (with lots of versions to support) they are reluctant to add an interpreter for AGS unless they control the code base, essentially using scummvm as the runtime for AGS, entirely replacing the ags runtime.
Since obviously CJ is not happy with that idea there is something of an impasse and so it seems unlikely that this will happen for a long time.
I'm not a developer at all, but I think your asumptions seem wrong. Here is my point of view about how the ScummVM project manages this, but I'm sure any ScummVM Team member would be able to explain it better than me.
Engine developers control their codebase as maintainers of that part. ScummVM is a big project composed of different game engines and backends, they are not an entity but a team with subteams. Look at the credits, they are a lot of people...http://www.scummvm.org/credits/
ScummVM is not a runtime, but a collection of them.
Also, there are different engines and the developers still work on them. Some engines already added to the master branch are constantly evolving to support more games of the same engine or improving due to different reasons (bugs, limitations, performance..). They follow a quite dynamic development model, they only have a short period of feature freeze and stabilizing the ports each 2-3 months but it's quite flexible too, depending on free time of developers (all of them are volunteers, with the exception og Google Summer of Code participants) and other reasons.
A good example is FreeSCI: They had an independent project and then the merge was debated. After different discussions, they merged and lots of code contributions to adapt it to the OSystem framework (the portable framework system of ScummVM) got done. Most of the original developers still contribute to the code and some new developers got into contribution shortly after. They are working to improve the SCI engine constantly, the support improved in a very substantial way after the original merging.
So the idea would be merging the engine to be part of the family, not replacing it. They want to avoid competing, their way is collaboring in the most transparent way. They want the original developers become part of the project and becoming part of the engine subteam.
Short answer: They want the merged engine to become the main one, not playing to catch the official one. They want the original developers to agree and collaborate on it in a symbiotic way, not competing to show who's the best or being a second citizen.