For me after using ModX in production for a few months would be:
1. Make/Adopt a more clear package management system that can be run in command prompt or in the modx install.
If I could throw up a gemfile/composer.json-esque file into a folder and scaffold my modx directory with a 'modx install' (or composer update) that updates all extras (and fresh install ModX) directly from github, I'd be the happiest camper; It would allow us to stay up to date without having to deploy a dev server for a bash script git fiasco to pull and relocate files.
My biggest complain with ModX is the inability to bootstrap it for instant setup, while also being able to version control the entire process through git (this includes chunks and snippets) before launch. It might not be everyone's workflow, but I believe a separation between web files and content is just as important as the separation between model and view.
I personally think there's a lot for all cms's/frameworks to learn from rails, but the biggest problem is everyone is trying to be so much LIKE rails they forget about what was good about their own platform. If the modx developers could figure out what are the most commonly used features, and develop ways to scaffold these features quickly without forcing styling and coding limitations like many of the current Extras do, things would be so much easier! This is a topic for another discussion of course
With that said, and it might make me sound like a hypocrite, but I really love the package manager. Post deployment, I've definitely seen my fair share of use out of it. Keeping this is a must!
2. Rethink Extras. I have been tempted to contribute my custom extras, but it's really just too complicated to quickly deploy an additional set of features while being organized doing so! Many of the potential code for extras I write end up being so hacked/mashed into the Modx tree that It would take too long for me to reorganize and extract it into a package (while maintaining my normal busy workflow in and out of work). If new features felt like they were intended to be more modular, extracting potential extra packages would be more bearable. (For instance, if there was an extras menu that was populated by creating a 'new package' in modx that you could start scaffolding the CP and your view, that would be amazing.) Because of this it also makes it really hard to contribute to other peoples extra code because you usually end up having to look through many files to try to tie which chunk from a chunk belongs to which chunk that calls which snippet's chunk. Issue tracking on github for modx projects was a good start, but pulling directly from and scaffolding git repos (master or whichever branch we want) is a necessity.
At least some sort of default differentiation between site elements and feature elements would be good. We currently have folders for sorting, but it gets tangled pretty quickly. Chunks are too good! The idea of creating a new "modx extra", it be seperated from the site chunks, and an easier front-end development for related fields would be amazing.
3. I've been making great use out of migxdb; I really do think MIGXDB needs to be implemented into the core of 3 with a much better UX/UI (no offense bruno, I love you for your work.) I'm honestly using it more and more for every project because it can solve so many issues. If we could scaffold a MIGXDB with a custom CP faster using a GUI and a db model thats more flexible and automated, that would save so much time in development, and allow more rapid feature development for clients. Some other CMS's are implementing this as a "Gridfield", but they're rediculously hard to implement even for an intermediate programmer...
4. ExtJS.
Too long didn't read version:
1. Git based package management like composer/rubygems using json/gemfile type setup (can be used to install modx core files from repo).
2. Better direction on extras, making them more modular(file-side) and in a seperate, but visible location in modx for easier editing and development. If extras could automate use of migxdb for their purposes, the masses that hate manipulating SQL (including myself) would be more apt to write new extras. If i could think about databases like excel spreadsheets, and modify their properties like so, developing db-driven extras that dont have stringent requirements for datatypes (or even with them) would be cake.
3. Add MIGXDB/MIGXTV's (old migx) to CORE with enhance UX/UI for rapid developement of (detached-feeling) alien tables for non-cms tabular content.
4. ExtJS
Keep up the good work!
I hope to contribute in the future. (might take my hand at the 2.3 UI redevelopment.)
☆ A M B ☆