I really don't have much experience with Sharepoint, but I thought I could at least provide some answer - even if it's the wrong one.
From another dev I've spoken to it sounds like it's tough to get into any subfolders, so you might need to look at making your own custom workflow.
Maybe something like LINQ to Sharepoint might be able to help you with actually getting in and enumerating the subfolders and getting to the data that you need? LINQ to Sharepoint
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!
Best Answer
I would personally try to avoid using folders. In numerous instance I've found they arn't worth the trouble and the key with SharePoint is not to reproduce the typical folder hierarchy that you'll find on a file system. Break away from that mess and do it the SharePoint way and put the documents straight into the list and use views and metadata to break up the documents into manageable groupings.
That said, a folder is it's own content type and it works perfectly well in a lookup column. You have to reference the list item id for the folder of course. I just created a folder in a standard document library, added a lookup column to a custom list and successfully referenced the folder in a new item. When I click the folder lookup then I get taken to the folder item, which contains an "Open" link that takes me to the documents contained within the folder.