I do understand that the problem is non-trivial. It does seem, however, like there must be some way that it could work…
Consider how the Windows filesystem itself works. If you delete a file and then create a new file with the same name (during the same session as the same user I assume), the creation date of the new file will be the same as the original file. The file contents and properties will have changed, but the file pointer remains the same. In fact this works even if you create a new file under a different name and then rename it to the file you just deleted.
If you see that a particular user deletes a file and then within some time window creates a new file in the same space with the exact same file name, it might not be a bad thing to assume that we want a new version of the (deleted) file…. especially if the original (deleted) file had a versionable aspect. I assume that Alfresco doesn't just completely remove all references to deleted files.
Anyhow, I understand that I'm not going to get a solution here, and I'm not really upset. It is unfortunate, however, because I can't maintain compliance if there is a trivial way to get around an important business rule. Of course this is a problem of accident and not malice, but it's a problem none-the-less.
In fact, it looks like I would have to lock down applications on client desktops to only those approved to work properly with Alfresco CIFS. This creates a dependency on Alfresco and makes the system rely on client configuration over the server. It's not terribly uncommon for an application to delete a file and re-write on save. The thread referenced above mentioned both vi and gedit, and heck even I've written applications that worked that way (blush). The application that actually sparked this thread is Seagull Bartender Enterprise which is relatively new. I can use Alfresco without CIFS (or WebDAV for that matter), but it's a shame because that would have worked so well, especially for stubborn users.
