To my knowledge, this is the list of things we need to do before cutting the v2 release (with folks named as being the closest/most knowledgeable on the questions, not assigning them).

Hard blockers

As long as we solve these, I believe all the others listed as Soft Blockers could actually be punted by shipping what we have as v2 with a not-that-long-from-now v3 to follow.

• design and implement compatibility story so the ecosystem can have a story where apps and addons' direct and transitive dependencies can include both v1 and v2 versions of this, so that we do not end up having to do a "big bang" migration across the whole ecosystem (@rwjblue)
• address Embroider compatibility in the build for the v2 addon; related to the previous point this may mean tweaking the v1 build as well somehow? (@ef4, @rwjblue)

Soft blockers

• decide whether the result of RFC: Glimmer component Signature type emberjs/rfcs#748 should be blocking for v2 (likely we need to support the new API in both the v1 and v2 branches, but it'd be nice to not have to support the old API in the v1 branch so that at some point we can drop support for the old signature as the ecosystem moves to v2 (@chriskrycho)
• finalize design decisions for v2 public API (removal of willDestroy etc.) (???)
• support <template> as the authoring format, assuming First-Class Component Templates emberjs/rfcs#779 is merged ~a week from now (@chriskrycho)
  • we should also decide what that means for existing users of the hbs design: do we deprecate it in the next beta and then switch over in the release? do we deprecate it but support both for v2? etc. (@chadhietala, @chiragpat)

There may be others I've missed; please list them below and I'll add them.