I think it's important for people realize that, even if you're not a PHP dev, there's a lot you can do to impact the direction of the project.
In my opinion, MODX LLC / Open Source Project should primarily have a leading role in the direction of the product and supporting the community, but the actual implementation and translation of that direction should be heavily community-focused. This means that user interface designers in the community need to design how a new feature looks, while non-coders should be documenting use cases. Developers in the community can then do the actual development in a way that matches the design and use cases, and then they can work with other core contributors or the project leads to make sure it's ready and will allow the future flexibility MODX needs. While an important step, development is only a part of the story.
As for the ideas proposed by Oliver:
1. Show me how that'd work, cause I can't imagine it yet. From the surface, I'd think ClientConfig-like Extra may be more appropriate as there's probably a number of conflicting use cases a core addition would need to cater for.
2. I think Bob's suggestions here:
https://forums.modx.com/thread/82926/modx-3-security-system#dis-post-460231 along with a properly designed interface would be a huge step forward for ACLs. Needs use case documentation and design.
3. I have not managed to completely understand the inner workings of FC and in my opinion it needs to be completely reinvented, starting with use cases and design. I think there's bigger problems beyond syncing "create" and "update".
4. I've not heard anyone opposed to this, so make it happen; this is not a breaking change but I'd personally recommend deferring to 2.3 as it may render product screenshots out of date.
https://github.com/modxcms/revolution/edit/develop/core/lexicon/en/default.inc.php
5. Agreed. I'd probably suggest it for 2.3 also, and this might do with some thought / documenting / design of how it should show the results. Different trees per element type or would the different icons be enough differentiation?
6, 7. Not sure. Useful but tricky. Maybe as addon or incorporated into Ace/CodeMirror RTEs would be better?
8, 9, 10: "content elements" in 3.0 - I believe Jason has some thoughts on how that could work but I reckon there's a lot of interface design work that should be involved with that.
11, 13: A completely new, reinvented UI for 3.0 would be great and put MODX ahead of the rest.
12: I made some minor improvements to the media browser in 2.2.7, but I think this could use a use case and design focused overhaul. Possibly in 2.3 but if too drastic in breaking backwards compatibility 3.0.
14: Pretty sure the core allows for that right now, so could be part of 2.3.