Most of that sounds reasonable to me.
But forgiving my ignorance, why would the hooks for deployers go away? How would deployers add web metadata to a deployment?
I think what you propose makes the most sense. There's no way every little detail of everything our underlying projects support is going to be configurable via the domain. What's configurable via the domain is the stable configuration that we expose via our management tools. Stuff that's stable and that users are likely to want to configure should go in the domain config if they can.
For things that don't get into the domain schema, some users are still going to want to poke under the covers and tweak things. So, "relatively hidden away yet user editable" makes sense. The key thing is the contents of those files are not going to be represented in the management API, there's not such a strict compatibility guarantee going forward, and the domain management infrastructure can't be responsible for keeping that file in sync around all the servers in the domain -- that's the user's responsibility.
A question is what is the "relatively hidden away" location. A simple choice is a resource in the JBoss Web integration module. Issues with that:
1) Patching. If users edit this file, and then a patch that comes out that modifies the file, we have a conflict and the patch fails. I don't see this is an argument against putting this in the integration module; the patching process is going to face this problem elsewhere.
2) Single shared web.xml across the domain, i.e. if you have multiple server-groups in your domain and they use different web container configs, they must use the same shared web.xml.