As an Android developer who has reluctantly moved to Gradle+Android Studio, here's what I think are table stakes for an Eclipse-based solution:
1. Acknowledge that for better or worse, the Gradle build system has won. Any Andmore solution should be capable of importing an Android Gradle project successfully. This probably means doing a lot of work on Eclipse's Gradle support, which is shoddy the last time I looked. This also means things like build variants and flavors.
2. As part of 1, ensure that AAR dependencies are first-class citizens. Eclipse/ADT can't handle them at all. The android-maven plugin team did some great work making it function from the command line but it's useless if it can't be done in the IDE. A lot of useful libraries (RxAndroid and RxBindings, Play Services, etc) are distributed as AARs, not JARs.
3. Also related to 1, ensure that Andmore can build multidex projects. ADT was totally incapable of doing this, meaning I had to build and deploy from the command line, and attach a debugger after the fact. This KILLS momentum during development. In a perfect world multidex wouldn't be necessary, but it is.
Some nice-to-haves:
* Eclipse/ADT had some hard-coded language levels that prevented the use of Retrolambda to use Java 8 syntax in projects - even if it was configured in your build properly, the IDE just would not let you set the source level to 8 and flagged all instances of those syntax features as compile errors.
* Steal shamelessly some of the editor features Android Studio has such as showing the actual String value of R.string ints in the editor.
All that said, I don't know enough about the internals of either Eclipse or the existing ADT code to know how much work this is. My guess is, quite a substantial amount. Is the ADT codebase even flexible enough to be altered this way or does this entail a from-scratch rewrite that simply takes bits and pieces from ADT?