The idea looks good but in fact there AS is a client for httpd so different keys will be used.
Even if JBossWeb acts as a server and mod_cluster.sar acts as a client in their relationships to httpd I would still maintain they could both use the same key and trust stores. The key presented by the JBossWeb on an SSL handshake could be the same one presented by mod_cluster.sar during mutual auth. The trust store used by mod_cluster.sar on an SSL handshake could also be used to validate the client cert from httpd during mutual auth. This holds true as long as the actors in the SSL communication are always viewed as the JBoss AS process and the httpd process. If one wants to distinguish between the JBossWeb service and mod_cluster.sar service in the creation of their keys then yes different configs are required.
Wearing my JBoss administrator hat, I have to make JBoss as simple and consistent to use as possible for hundreds of novice users. Sharing a config with JBossWeb is not my top concern just an added bonus of using a JaasSecurityDomain. I'm more concerned with a consistent strategy for defining SSL configs. It is a pain to have many different locations for defining key and trust stores, as outlined in my original post. JaasSecurityDomains appear to be the direction that other JBoss projects are taking. This adds consistency for reducing the learning curve for new users and promotes reuse of configs where appropriate.
I am going to go ahead and create a feature request for this unless there is some reason why this couldn't/shouldn't be done.