When DeploymentHandlerUtil.doDeploy passes the Resource for the deployment into RootDeploymentUnitService, it is from the currently executing management ops version of the resource tree, and becomes the "official" version once that op commits. But once another config write op commits, the Resource instance cached by the RootDeploymentUnitService and attached by it to the DeplopymentUnit is no longer the official copy; it's a previous copy, aka "cruft". So any mutation to it is not affecting the official copy.

Where this can be an issue is if the deployment services stop or restart due to MSC dependency changes (i.e. some service depended upon by the deployment stops or restarts), but not due to deploy/undeploy/redeploy ops affecting the deployment directly. The stop/restart will trigger the DUPs which then may attempt the out of date "cruft" Resource.

WFLY-4908 is an example of such modification.