All of the concern about varying versions of the Word ApplicationEvents2 interface was pointless. Word 8, Word 11, and Word 12 expose the same 12 events. I don't have access to Word 9 or 10 but I think it is safe to assume they will follow the same pattern. So it truly is a "design time" issue--as you initially pointed out--and the same handler class can be expected to work with all versions of Word from 2000 through 2007. I am so confident of that fact that I am releasing the edit module into the beta environment today. The flakiness is gone. I've stopped worrying about NewDocument (users can create as many as they want since they can't save or print them anyway) and I am not going to try to modify the menu or commands. If the code survives beta test in this client's environment, it can work anywhere! I won't be the least bit hesitant to offer this to other clients.

It is exactly the solution I was looking for: the user can modify the document after the data has been merged, but the VFP application controls Save (including the document name and location) and Print. There are at least 100 users who will benefit from this. At some point, I may revisit my attempts to use GetObject() as opposed to CreateObject() for the Word reference in order to improve performance. Right now I'm just thrilled to have it working.

Many, many thanks for all of your help!