Most of the problems that I ran into with AS 4 farm deployment were usually with the file system not allowing the user to express the actions that they really want performed. My workaround was to tell users to avoid ambigous file system operations (don't delete a deployment on a stopped AS 4 cluster node).
The tags are an excellent work around (they allow additional actions to be expressed by the user that we couldn't do in AS4 land). Even, better would be to eliminate scanning of the file systems for deployment and instead allow external tooling to handle the same functionality. This would be in the form of an external file system scanner that deploys/undeploys by interacting with the AS admin api. This could expand into other kinds of scanners, well beyond the file system (e.g. deploying applications as they are checked into git or perhaps draggedNDropped onto a webdav server).
The flow would go something like:
1. Start the AS
2. Launch the "old school" external file system scanner, passing AS server connectivity options. It starts scanning for deployments.
3. If a current deployment is deleted from the "old school" folder, it is undeployed. If a deployment is copied in, it is deployed.
Perhaps you like the tagged approach, so you instead launch the "tagged" external file system scanner, which works mostly like the current AS7 file system scanner.
Maybe later, your boss wants you to track every application that gets deployed. So, you launch the "git" external scanner and that tracks history for you.
I'm not sure if this helps for AS 7.0, but if this approach is desireable, we could design for it and maybe build enough to satisfy the tagged and non-tagged approaches (we only need the admin api and to create the external old school file system scanner).