As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.

The obtained defect:
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)

FIX:
We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e69c562c40
Changes: The method getSynchronizationType returns declared synchronization type.
WFLY-7108 is now the tracking jira for the fix.

Consequences:
We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
It requires a declaration of synchronize persistence context.

We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.

However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.

Our actions:
We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
Commit: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d896183ed2

Example for reproduction:
I modified quickstart example: kitchensink-ear.rar
MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
MemberRepository also perform join Transaction.

Questions from smarlow@redhat.com:

• whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
  We decided to use Container-managed EntityManager, because
• Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
• The container makes our job
  We want to use the existing mechanism

In Addition:
Formally, this is out of JPA SPEC, but we have the following reasons:

• In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
  But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
  ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/message/5 )
• We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"