As a member of the Errai team at JBoss, I just wanted to jump in and correct a few of your assertions here before any bad rumours get started.
There is no part of JPA that we ever claimed was unsupportable. We've started with a useful subset and we're working with the community to add new features as people find use cases for them on the client side. Most recently, we added support for abstract entity classes based on a request in our forum. Also, there's currently a community member who's thinking about contributing support for @Embeddable types.
As far as needing to rewrite to add a feature, the errai-jpa code base is very clean, has plenty of API docs, and is thoroughly covered by JUnit tests. You can undertake a significant refactoring without fear of accidentally breaking an existing feature.
The errai-jpa code is also modular: the EntityManager implementation is fully separated from the underlying Window.localStorage backend by a StorageBackend interface. The idea is that one day our community might find a need for IndexDB (or even WebSQLDB) support and implement it. Thanks to the robust test suite, the exact contract of StorageBackend is negotiable.
Also, there's one incorrect item on your list of things we haven't implemented yet: we do support multiple persistence contexts. This feature is used by our errai-jpa-data-sync module for tracking the latest known state of entities on the server, but of course you can create additional persistence contexts for your own purposes.
Why not join us? Pick an aspect of our JPA implementation that's missing and you can't live without, then work with us to add it to what's already there. We're very friendly and always available to help contributors get their bearings on the errai-dev mailing list, #errai on FreeNode, and our web forum.