Here's what I'm doing. Following uses the term "auto-deploy" to refer to the scanner deciding to deploy without being told to via a .dodeploy marker.
1) I'm adding the zip scanning Jason mentioned to detect whether the zip is complete. This is the basis for reliable auto-deploy of zipped content.
2) Reliable auto-deploy of exploded content is not possible. As a safety aid I will use the scanning code from 1) to check any nested jars, but that doesn't make it reliable.
3) If auto-deploy is available for a type of content, a .skipdeploy marker will prevent auto-deploy of a particular file.
3) I'm going to add an "auto-deploy" flag to the deployment-scanner element, with legal values "ALL", "ZIPPED", "NONE". Flag controls what types of content auto-deploy behavior is enabled for. Per Jason's statement above, default is "ZIPPED", as "ALL" cannot be made reliable. Configuring "ALL" will result in a WARN message in the server log.
4) For auto-deploy of exploded content, there will be no deployment descriptor file timestamp check as the means of detecting the need to redeploy, as in EE 6 there is no universal requirement for deployment descriptors. And checking the directory timestamp is not valid as it's easy to change content without triggering a change in the directory timestamp. So, with auto-deploy if any file in the deployment changes, the deployment gets redeployed. People who want to change content without triggering redeploy are going to have to use marker files; either leave auto-deploy disabled and use .dodeploy, or enable auto-deploy and use .skipdeploy.
5) If a scan tries to use auto-deploy for a file and detects incomplete content, the scan will be aborted (i.e. it will be as if no changes were detected.) The next time the scanner runs, it will check again.
AFAICT, this is essentially completing what was discussed in Antwerp and detailed a few pages back by Max. Difference is auto-deploy of exploded content will not be default behavior.