Looks great!
package.json
Fewer packages make it easier to upgrade, less overwhelming for new users. For instance, can the packages ember-resolver, ember-load-initializers, ember-cli-htmlbars be hidden under the ember-cli package somehow?
Great roadmap! 
For the product I work on, the number one item on our wishlist is:
The other items are also good stuff, but they are secondary to module unification (we have a fairly large app, 115 components, 136 routes, etc so the current structure is starting to break down). Module unification would be very helpful for us!
Regarding the website, I think merging with emberjs.com would be good. Especially for newcomers! If needed, it could still be a separate ‘build’ (similar to how the API and Statusboard are separate pieces).
Single file component!
Single file components is largely an Ember feature (which is already possible technically)…
Totally agree with this. Our organisation almost gave up entirely on ember due to the issues in trying to get ED working with .net backend. Fortunately we switched yo using AJAX requests and we didnt throw out the baby with the bath water but the documentation should introduce ED far later and not thrust on us by default.
Module Unification!!!
I would also love if the Ember CLI docs were in the main Ember site as well.
Don’t you need Ember CLI to split the single file and compile each part individually?
Making the ember builds independent of the build tools. Ember CLI can expose a build API which build tools can use. Officially Broccoli integration for the build API will be supported by the CLI team but the wider community can come up their own solutions with today’s hotness such as Webpack. Packaging Strategy RFC proposes to support this feature partially but would love see ember builds become completely independent. This will open up a new area of experimentation around ember builds.
All the other ideas are also good but this list is what matters the most to me
I would offer a mode that relies on browser ES6 support and skip the build altogether (read this). It’s a dream I’ve had for a long time and that I recently started to implement (not in Ember though). I really love the simplicity it brings.
Development mode As developers, we use the latest technology browsers. We can already use most of ES6 in Chrome. Why would we need compilation altogether? If we remove compilation, no build time. We start the server and we are good to go. Oh and we wouldn’t need sourcemaps anymore. The only exception would be css processors and templates.
Compiled mode We still need compilation for browser support. A production mode would let us run the compiled code. It might even be the mode we would run if Ember moves toward TS like Glimmer did.
I totally agree on that point. Sometimes I write ember-cli addons and it’s always a “pain”. I’m never quite sure if my solution is “good” or not… Also, tips and tricks for developing ember-cli addons would be nice. For example, I read on some blogpost how to use node --inspect-brk in conjuntion with developing ember-cli addons.
A good (maybe visual) explanation of Broccoli and it’s trees could be also helpful.
These points are the main points why I had to write ember-cli addons. Most of the time my custom addons are here for creating separate bundles, creating inline-css, inline-scripts and things like that.
Speaking of bundles, I think it would be great to create at least two different bundles. One for modern browsers with full ES6/ES2018 (or however you want to call it) support and one bundle for legacy browsers which is compiled back to ES5. This way we could use modern features (like async/await) without degrading the performance for all users.
And there is one huge pain point. Hot reload of CSS with ember-cli-sass just doesn’t work on my machines anymore. If you want to restyle something you always have to go through the whole build process and in worst case have to click through the UI to create a certain state. This is even more annoying if you try to solve some CSS bug and you are not 100% sure how to do that. Of course, you can use the dev-tools but sometimes it’s quite involved (sass variables etc) and it would be nice if you wouldn’t have recopy all the stuff from the dev-tools to your code.
But overall ember-cli is an awesome project! Thanks for all your work and passion.
One thing that I haven’t seen mentioned here, but actually seems to crop up quite a bit in the form of confusion when chatting with folks is the fact that ember-cli itself does not have an LTS policy. Commonly, folks that are trying to stick with a given Ember LTS version will stay on that “version paired” ember-cli version as well, however this means they are missing loads of bugfixes, Node version support, etc.
I’d like to discuss adopting Ember’s LTS policy for ember-cli…
I’ve worked in several corporate environments. I always just went ahead and used shadow IT. My direct manager would always be supportive.
That said, there is an effort to use the official OS TEMP directory rather than ./tmp , it could use some help.
Do Ember plan to move from their object model to ES6/ES7 object model to use class and decorators out of box?
Also it will be great to start use routable components.
One thing that would be really useful is a way to generate a breakdown of which addons/libraries/etc make up the app+vendor build sizes.
I’m sure there was a way to generate a visualisation of that at one point but I remember it being hard to find (I’ve now lost it again 
) and poorly documented.
it’d be nice to have something out of the box for sure, along the lines of broccoli-concat-analyser
I always use soure-map-explorer: GitHub - danvk/source-map-explorer: Analyze and debug space usage through source maps which works quite great for me 
Thanks for all of the awesome conversation, ideas, pain points, etc. I believe we had a very successful ember-cli core team meeting this past Thursday…
We will try to come up with a better write-up of what we discussed, various “resolutions” of those discussions, and our general team roadmap soon…