I'm not sure how more than one person can truly be in control of something, unless you have a very robust voting process or consensus committee for every change. The slowness, I'll admit, is partially our fault - we've been working on making it possible to publish Blaze releases outside of Meteor for a long time, but we've finally done it!
As of Meteor 1.4.1, core packages can be updated outside of the release cycle.
This was a pretty big change we made specifically to enable this kind of mini-forking of formerly core parts of Meteor. We were planning on doing a similar thing with Accounts as well, back in the day, but we haven't found someone to be "in charge" of that section of the code. Perhaps it could be you!
I agree that a lot of work is going towards Apollo now, which is not a minor upgrade to the Meteor livedata system, but instead a "spiritual sequel" - in that, we plan to migrate our internal Meteor apps to this new data system soon, and we think we'll be better for it, for all of the reasons we mentioned when we started the project - backend independency, easier to tune reactivity, easy joins, and more.
It's a new feature for Meteor, re-packaged in a way that it can be adopted much more widely, ensuring it doesn't become "classic" anything.
Someone migrated Meteor to Node 4 - a relatively thankless project extremely important to the future of the platform. Those people put in long hours that aren't as visible, because it's not a "hot" new feature, but rather an important and big chunk of serious maintenance work that required reworking some big stuff.
We definitely have the hours to help someone like @ramez move to maintaining a part of the "classic" Meteor codebase, if you want to call it that.
I don't think there is any world where increased adoption of a community-driven Meteor hurts anyone.
Apollo is an independent project that adds one more choice to the data platform component - it's not going to contaminate anything. Do you feel like adding React support contaminated Meteor?
Well, the first question is - who should be owning this new repository? Mitar needs no introduction, we've all worked with him before and he's submitted countless patches to the core.
If there is some sort of community consensus about who should hold the keys to publishing new versions of, say, Accounts, then we can certainly make that happen on a very short schedule based on the work done in 1.4.1.