I've pretty much stayed out of this topic because my work is centered on Revolution now, but I thought I should throw in my $.02. This is just my opinion and not necessarily worth anything, but I don't think you can expect solid support for Evo. Not because the MODX team doesn't mean well by Evo, but because there just isn't enough programmer time available.
Now that they're working on the cloud platform, the small number of core programmers don't really even have time to fix the bugs in Revo, the Forums, and the main Revo add-ons.
If you look through the bug tracker, you can see bugs in all three that have been open for some time. I've filed a number of confirmed but non critical Revo bugs that have gotten the "fix version" pushed back several times because no one had time to work on them. I'm still seeing the blank console in Revo 2.2.2. The Forum has been mangling code, eating carriage returns, and throwing gateway timeouts for a long time. There's a pull request for a fix to a non-trivial bug in the ConfirmRegister snippet that no one (as far as I know) has had time to look at.
I don't say any of this to be critical, just to point out that the MODX programmer resources are limited. I would expect that Evo, important as it is, will not have a higher priority than the things I've listed (especially MODX Cloud, which is probably more important for MODX's long-term success than Revo).
The problem with Evo is that because it was developed so long ago and so many parts were tacked on haphazardly, it's almost impossible to add the functionality that would make it usable in the future. The underlying architecture is, frankly, a mess. The last time I looked, in Evo snippets, plugins, chunks, TVs, and templates each have their own separate code. In Revo, they all extend the modElement object which extends the basic xPDO object. Creating Package Manager in Evo would be a nightmare and it's really a necessity for a modern CMS. Version Control, extremely difficult to implement in Evo, is another example.
The same is true of essential tools like PackMan and MyComponent for creating Transport Packages. PackMan lets you build an add-on component in Revolution (if it's not too complex), then create a Transport Package for it by filling in a form in the Manager. I'm working on a version of MyComponent that will do the same thing with more complex packages. Again, both would be almost impossible in Evolution.
You can take an old, often modified, pre-OOP snippet and continue to shoehorn new features into it, but at some point, you rewrite it from scratch as an elegant OOP snippet. Evo, much as we all love it, is like that old snippet and Revo is the OOP version of it. There's no better example of this than what we ask the user to do to install an add-on component. If you look at the SPForm tutorial at my site and compare the installation instructions, you can see the dramatic difference. In Revo, you have a working contact form with a few mouse clicks. In Evo, not so much.
It's just not acceptable these days to ask a new CMS user to cut and paste PHP code in order to install or upgrade an add-on component.
I'm really impressed with all the energy and hard work being put into Evo, but I sometimes wonder if it wouldn't be better to build a new, Evo-like Manager for Revo that used Evo's security model and faster Manager, and Revo's Package Management and underlying architecture to give you the best of both platforms. Call it Revo-lite and it would be perfect for smaller web sites that don't need to scale or use the more granular security model of Revolution.
Public relations is definitely not my strong suit, which is part of why I've hesitated to jump into this topic. I sincerely hope that I haven't offended anyone with this post. I'm sure a more tactful person could have made these points in a much more diplomatic way. I want to emphasize that I don't speak for the MODX team here and that my assumptions may be way off base.
☆ A M B ☆
☆ A M B ☆
