OK I will attempt to answer as many questions as I can.
[Q] Is it correct that the audit should contain the update (and it's outcome), even if the transaction failed and also in the presence of a crash?
Starting off with the tough ones I see. :)
Currently our audit requirements are met by using syslog-style remote logging, which is done in a very ad-hoc manner (i.e. without sensitivity to crashes). It will be difficult, regardless of the answer to this question, to both meet the remote log requirement as well as dealing with the possibility of crashing. AFAIK there is no way to log to syslog transactionally.
Ignoring that problem though, my feeling is that we are only required to Audit (with a capital A) changes that were successfully made, but we do want to at least locally log (in a human-readable fashion) failures as well.
[Q] Can the ObjectStore that the application user configures be used by the MSC?
I think not. I think we will want to isolate the administration actions from the user's transactions as completely as possible.
[Q] Must the transaction/recovery manager allow separate object stores to be configured?
Only insofar as the previous requirement can be met.
[Q] When using the CLI to browse the object store to resolve transactions manually, must the MSC and application transactions both be visible?
Just application transactions. The MSC/management transactions should be separately recoverable, as the management system cannot be initialized without its database.
[Q] Should the transactions initiated by Transactional MSC be present in the user's view of the agregate statistics gathered by Narayana?
No.
[Q] Does it matter if the recovery manager recovers both Transactional MSC's transactions and the applications' tranactions?
Yes (see above).
[Q] Do MSC's transactions need to be recovered before the server finishes booting?
Yes.
[Q] Are there any configuration options in Narayana that cannot be shared between MSC and the applications? The issue here being that the user could make a configuration change that would be detrimental to the operation of MSC. Do we need to consider all those exposed via the ArjunaCore Environment Beans, or just those exposed via the WildFly managent API?
Yes. The object store should be separate as mentioned above. The recovery system should probably not be (directly) network-enabled for MSC. Looking over the environment beans, I'm going to say "yes these need to be considered". I see many parameters that seem likely to be able to cause trouble for the management system.