Just as a clarification, two questions:
I. Is it ok to use the context itself as a schema? For instance, with:
mix phx.gen.html Accounts User users email:string:unique
If I wanted Accounts and Account Users (multiple Users per Account), would I then run:
mix phx.gen.html Accounts Account accounts ....
II. With many to many associations (Tags and Posts for example), I presume it’s up to the developer to decide on one context (either Tags.Post or Posts.Tag, but not both)
Thank you @chrismccord @wojtekmach @josevalim and everyone else for making this happen! I really can’t wait to move our applications to the new structure and then from there to umbrella when people agree with the direction or they get to a bigger size 
Hello! I can’t understand proper web/* scoping now. Before I was able to do:
mix phoenix.gen.model User users ...
mix phoenix.gen.html Admin.User users --no-model
What should I use now?
I have opened issues to support the --no-schema and --no-context options. If folks would like to contribute, this is a great opportunity.
One more changelog entry that didn’t make it into the initial changelog from some of my colleagues 
:
mix phx.digest.clean to remove old versions of compiled assets
Is this nesting going to be a recommended practice Elixir-wide (so lib/ecto/ecto.ex instead of the current lib/ecto.ex) or is this a Phoenix-only thing?
Hooray! I’m a huge fan of the lib/web consolidation and how it lets standard approaches to breaking up an app into an umbrella app work smoothly!
I am just not sure how controllers should be scoped now (and views as well). By default generators output looks like controllers/order_controller.ex. But for example if you have 2 contexts - Sales and Support - should I create 2 scopes like controllers/sales/order_controller and controllers/support/order_controller, right?
Or what is logical structure for new design?