Identify important core issues

Mentioning #2329939: Unifying the revision checkbox in entity forms. New entities will not have "new revision" checked, but existing ones will if the Entity supports revisions.

Will also want to watch on #2248709: The root type of a configuration object can not be a sequence .

For what it's worth, these are the notes I passed on to some core maintainers very inefficiently (via e-mail) last year:

1. We didn't want to invest real effort into the migration process until the Entity API settled down. That seems to have happened now, but I haven't yet checked into the entity access system or entity revisioning to see how they compare to what we use currently in Commerce 1.x.
2. As you've guessed, having a solid Entity Reference then is essential to Drupal Commerce. I'll be replacing the product reference, line item reference, and customer profile reference fields with the core Entity Reference field. I haven't tried this yet, fwiw.
3. Another key aspect of this architecture will be embedding entity forms into other entity forms - i.e. embedding the line item add / edit form into the order add / edit form using the "Inline Entity Form" widget we developed (http://drupal.org/project/inline_entity_form). Bojan tells me that the current architecture of form controllers in D8 will make this difficult, whereas before we could massage a form into place as a child of another form. I may have to just connect him directly to an engineer with knowledge of the innards of the changes to the Form API.
4. Revisioning in general is difficult to get right when dealing with the need to revision multiple entities at once. There actually is no way to reference a specific revision or another entity, so even if I made a new revision of my order, it would only point to line item IDs that may or may not exist any more. For example, a previous revision of an order may reference a line item that no longer exists, so when displayed I'd see the order total from that time period but only the line items that still exist.
5. If I had to guess, I think this means we need both entity revision referencing (probably out of scope for D8) and the ability to delete an entity but retain a historical record of its existence if its previous revisions are referenced. Again, pretty out of scope for D8, and the latter at least is probably doable in contrib.
6. I think this is in now, but we really do want to be able to attach comments to anything. I'll test that. : )
7. I think this has been broken in Drupal for a long time, but I'll need to reinvestigate unless someone on your team knows off the top of his or her head: basically, exempting fields from the form cache doesn't seem to work. This is essential to be working for onsite payment forms, though we still conform to the "letter of the law" in the case of CC payments since data protection rules are tied to the time of authorization. Still, it's a fine distinction to draw. : D
8. I've found it to require a fair bit of boilerplate to simply define a new entity type - I'm 6 classes in and maybe half way there. Any effort spent to reduce the amount of code required just to define a new entity type would be fantastic.
9. We're planning on establishing product groups using some sort of hierarchical pattern. If a generic entity hierarchy system is in the works, it'd be good to know about and possibly contribute to - such as any efforts to abstract the book hierarchy.
10. Finally, it'd be nice to just have some guidelines for developers to know when to write a plugin vs. put code in a module vs. put code in a class vs. a service, etc. I want Commerce to make the best use of the appropriate new systems / patterns we have, but it isn't clear what should be what, and in core it seems like a lot of code remains in .module files that should be in a class.

Funny to look back on my notes now that entity reference actually supports revision referencing. : P