Are you manually editing those xml files to add the deployments (while server is running)? You shouldn't be doing that. Instead use the tools like admin console or the CLI to add the deployments so that the management API is aware of those deployments.
We are editing that file (via XSLT) prior to ever starting the server, not while it is running.
The deployments element is handled by the management actions, if you need to change it I recommend to use CLI or management console.
If you add something by hand the server management might remove it if the deployment failed.
The deployment-scanner is different as here you have so called unmanaged deployments and you can add remove it via filesystem and it's marker files
I eventually figured out how to deploy an exploded war directory via the CLI. It was far from obvious to me at least:
That said, that doesn't help.
A deployment failure in an exploded application deployed via the deployment scanner causes the explicitly specified <deployment> elements in standalone-full.xml to be removed from the configuration. This occurs irrespective of the value used for the auto-deploy-exploded attribute. The deployment scanner tries to undeploy all applications upon the failure of one application and removes the <deployment> element entirely for explicit deployments of exploded applications.
Manually deploying everything via <deployment> elements seems to resolve the issue. If approached this way, a failure in one application no longer makes any attempt to undeploy other applications -- which would seem to make far more sense. Also, other automatic changes to the standalone-full.xml file (e.g. a change to a log level via JMX) do not remove the manually inserted <deployment> elements, so this errant behavior seems quite specific to the deployment scanner.
Overall this really seems like a bug in the deployment scanner behavior and I have filed WFLY-3726 accordingly.