I understand the situation.
I've not performed a detailed comparison, but I'll share my relevant reasoning.
I like to keep options open, and available, and SpringSource is so far has confirmed their commitment to STS, in a certain sense just as Genuitec & Skyway did for ME4S.
But STS seems offers much more diversity also in terms of interoperability with other technologies and vendors. Things that come to mind are Roo, Grails, Groovy, Cloud Foundry, etc.. And since its under VMware's direction, it feels very reliable to bet on it, too. Perhaps just a little bit more, since STS is dependent on a different business model, and seems much more adopted and familiar to Spring-oriented Java developers.
ME4S is brilliant in terms of fast project startup speed, and high productivity development & maintenance friendly tools. Especially since alos just as Google tec friendly.
So I'd rather not choose between the two, nor "reverse-engineer"/analyse/deduce/etc.. the relevant SpringSource's reasoning used on their directions, from experiencing the overview of the tools, and and advocate that for ME4S team.
Both have a different set of strengths and weaknesses, also in terms of speed in certain parts of the development stages, and the need to restart (a heavy) workbench to use another profile to use the right tool, for the relevant development stage, or project.
I'd prefer, if ME4S at least was possible to add to a Classic Eclipse 3.7 Indigo profile, on top of MEC Pro ( Http://downloads.myeclipseide.com/downloads/products/eworkbench/indigo/enterprise-stable/
) which can coexist with STS.
Does ME4S offer at least the possibility of such a coexistence? Aside closer integration, not minding overlap in covered featured, as long as installable. Or should users that using similar reasoning as me, realize that there is a fork in the road, and keep it in our mind when making our decisions or advice others in that regard, in the future?
I understand that coexistence of similar features is a problem at the richness of an IDE level, not just simple plug-ins, but I believe it's key. And I believe that the MEC Pro "compartmentalising"/dividing of the features into separate plug-ins available from the above mentioned update site, did a great job to allow STS to be used in the same profile, instead of its --in comparison-- less sophisticated Spring tools in that case.
Perhaps if the ME4S team is indeed convinced that user's interest for the ME4S STS Edition probably won't increase to be enough to be enough to motivate a revival as newer releases, then perhaps it would also be user friendly --in terms of removing the coexistence-based hidden choice-limitations-- to treat ME4S's distribution like that of MEC Pro, to allow a more refined selection of the needed features, and offer the needed update sites for it too.
Based on their feedback, I'd know what to do in my own case. Right now, I'm still using Ec 3.6 + MEC & ME4S v9 STS Edition + STS, but I want to switch to the new profile I've set up using Ec 3.7 + MEC v10 + STS, and preferably have ME4S included in the same profile.
To be blunt, it really sucks to restart my profiles, I've set up the whole thing to give me maximum options to build, test, etc.. most Java open source projects, and test technologies and tools in the same workbench, and in the same workspace. I even have set up a project naming-convention to keep a healthy level of overview in the same workspace, which is needed, even when using 'working sets', when the list of projects in the workspace grows.
The possibility of easier coexistence is really an important key. The reputation of MEC Pro suffered a great deal from the feedback of my own surrounding back when it was at the ME4S level in terms of that which I've tried to clarify above from my own perspective. And they were right, I had the same issues.