There are some good reasons for wanting to do this but there are other ways to accomplish it than extending XAResource. One way (we did this as a WebSphere vendor extension) is as an extension to the resource-reference. We found this a simple way to enable different apps to use resources in different orders without polluting any runtime beyond the TM and ConnectionManager.

Please can you clarify the use case that this feature is intended to address? I think that there are at least two interpretations of what this Jira could be intended to address:

The first interpretation I see is that we will support explicit ordering of commit completions (we won't move on to the next resource until we receive any true completion value, i.e. any value that is not an XAER_RMFAIL). A feature like this would be able to address use cases such as "race conditions". There is a good article describing race conditions of XAResources here:http://jbossts.blogspot.co.uk/2011/04/messagingdatabase-race-conditions.html.
However, providing a capability to address the issues discussed in that article would require the Transaction Manager to wait for completed commits (i.e. retry the commits for resources returning XAER_RMFAIL before moving on to higher order XAResources). This would couple the transaction manager into the business logic which is not desirable.
For example, if we do not wait for the commit completion message (either XA_OK or a heursitic) the user will still need to add business logic to compensate for data unavailability which would be unexpected and (in my mind) undermine the value of the feature should the programmer be expecting an "explicit ordering of commits" (I allow heurisics as this feature does not mention it is intended to address heurisitic outcomes).
For example, consider a database (DB) and message broker (MQ) resource pair where you want the DB to commit first so the MQ can view the revised state:
DB.prepare()
MQ.prepare()
tm.log();
DB.commit() -> returns XAER_RMFAIL
MQ.commit() -> business logic fails as expected db rows are not yet committed
DB.commit(retried)

The second interpretation I see could be that we will support explicit ordering of commit attempts. In this case we would move onto the next resource regardless of the result of the current XAResource.commit(). A feature like this can support use cases that do not couple the transaction manager to the business logic (i.e. in the event of a commit failure, the transaction manager is still at liberty to move on to higher ordered XAResources).
For example if certain XAResources are more "probable" to fail, a developer may wish to attempt those first. However, if this is the intended use case, I think that the feature would be better described as "support explicit ordering of prepares for XAResources enlisted in a transaction", or possibly "support explicit ordering of commit attempts for XAResources enlisted in a transaction".

"providing a capability to address the issues discussed in that article would require the Transaction Manager to wait for completed commits (i.e. retry the commits for resources returning XAER_RMFAIL before moving on to higher order XAResources). This would couple the transaction manager into the business logic which is not desirable." - I think that if the users explicitly state that they want the ordering of the XAResource commits (for example DB first, JMS later), then the Transaction Manager should simply obey this. Such coupling of TM to the business logic is quite light in my opinion, and it is fully justified by the fact that otherwise the race conditions between the JMS commit and the DB commit have to be handled in the user code, which is ugly.

Please could we also include Synchronizations in this discussion. I know we already have limited ordering semantics with interposed synchronizations as standard but we have had other ordering requirements from the JCA (and I think JPA) teams within the wildfly application server. What I'd like to see is an interface that allows us to order some synchronisations relative to each other and allow others to run as normal - ie the synchronisations would form a partially ordered set where we have the choice to run independent partial orders in parallel.

I don't think that adding more requirements to this Jira issue is a good idea because that it has been originally reported in December 2011, it is still not resolved and there is not even any progress visible. Regarding Synchronizations there actually is an easy solution: register only one Synchronization which would be implemented to allow runnning other Synchronizations with any order you like (composite pattern).