Finally, we got through the support services processes at Microsoft and got a solution!
First, Microsoft stated this to be a bug. It is a minor bug, because there is a good workaround, so it may take some longer time, until this bug will be fixed (the support technician said something with next service pack oder next version (!)).
But now for the problem.
The reaseon
Let's take a look at the CAML code from my question:
<Method ID='1' Cmd='Update'>
<Field Name='ID'>1</Field>
<Field Name='myDummyPropertyField'>NewValue</Field>
</Method>
For any reason the Workflow Manager does not work with the ID, we entered in the second line. Strange, all other SharePoint commands are working with the ID, but not the Workflow Manager. The Workflow Manager works with the "fully qualified" document name. So, because we had no clue and didn't entered any fully qualified document name, the Workflow Manager defaults to the name of the current document library. And now the error message begins to make sense:
The object specified does not belong to a list.
Of course, the object (document library) does not belong to a list, it IS the list.
The solution
We have to add one more line to our CAML Query:
<Field Name='FileRef'>/sites/mySite/myDocLib/myFolder/myDocument.txt</Field>
The FileRef passes the fully qualified document name to the Workflow Manager, which - now totally happy - starts the workflow of the item.
Be careful, you have to include the full absolute server path, omitting your server name (found for example in ServerRelativePath property of your SPItem).
Full working CAML Query:
<Method ID='1' Cmd='Update'>
<Field Name='ID'>1</Field>
<Field Name='FileRef'>/sites/mySite/myDocLib/myFolder/myDocument.txt</Field>
<Field Name='myDummyPropertyField'>NewValue</Field>
</Method>
The future
Perhaps this undocumented behaviour will be fixed in one of the upcoming service packs, perhaps not. Microsoft Support apologized and is going to release an MSDN Article on this topic. For the next month I hope this article on stackoverflow will help developers in the same situation.
Thanks for reading!
The .aspx files are under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\templates\layouts
A quick and very dirty way to deploy new functionality (which is accessible to everything on the server) is to drop aspx's into this folder. This is not safe, but gives you a way to test things before investing the time to do a full blown solution/feature deployment.
I suggest reading up on Andrew Connell's development methods, I think he has a book for doing sharepoint development out too. His 'developing sharepoint features' talk is the best jumpstart into doing sharepoint development I've heard. http://www.andrewconnell.com/blog/
Best Answer
I'm sure you would have already checked this but is there any more information in the ULS logs?
Also have you tried setting the debugger to break on all exceptions and does this give you more information? Go to Debug, Exceptions and tick Common Language Runtime Exceptions. Then go to Tools, Options, Debugging and untick Enable Just My Code. Finally attach to w3wp.exe.
If you are running Windows Server 2008 you could also try taking a dump file at the point the debugger breaks above. ADPlus might help if you are running Server 2003 but I don't have experience with it. You should then be able to open the dump file with DumpChk or WinDbg.
Edit: As discussed in the comments, this is code deployed to production that can't have its service interrupted. The only way you could create a dump file is programmatically. Have a look at this question I asked that will hopefully help you if you need to go down this route.
Other things to try if you don't want to get down and dirty with debugging is to try deploying your custom bits to a clean server. See if you can still reproduce the problem or if it changes.