Due to popular demand, here are some answers to the questions.
Well, not answers exactly ... just some pointers to the get you in the right direction...
1. Are there advantages to building workflows using only XAML? Are there disadvantages?
See Keith Elder's blog on "Leveraging Workflow Foundation", particularly the section on storing workflow definitions in the database.
Also, see Matt Miler's Templates for Windows Workflow XAML activation projects
2. What are the pros and cons of using an ExternalDataExchange service versus going directly to the WorkflowQueuingService?
Sam Gentile: Windows Workflow 1023. When are attached dependency properties useful in WF programming?
See: Dependency Property Notes4. What behavior does the default scheduling service provide?
Hosting Windows Workflow5. How can my code participate in a database transaction with a workflow instance?
Advanced Workflow: Workflows and Transactions6. Why would I use a tracking service?
Follow the links in Tomas Restporo's WF Tracking Services Explained.
7. Describe a scenario where the WF runtime will cancel an executing activity.
I'd be looking to hear, for example, what happens inside a Listen activity. Also, see Matt W's Implementing the M of N Pattern in WF
8. Describe a scenario where I'd need to spawn a new ActivityExecutionContext.
Matt Milner: ActivityExecutionContext in WF.
9. Tell me why I'd use a compensation handler.
Guy Burstein explains the essence: Compensating and Fault Handling.
10. Tell me about the following activities: Replicator, Parallel, and Policy.
Advanced Workflow: Replicator Tips and Tricks
Kirk Allen Evans: Understanding ParallelActivity in WF
Sahil: Composite Activities in WF.
Comments
1. You really can't do anything more complicated then "Hello, world!" workflow. Or you should have very rich activity library. Or you have something like scripting activity (for ex. PowerShell) which allows you to do most of things you want.
2. Having workflow with delayActivity1 and writing declarative condition in, for example, IfElseBranch, you can't refer to delayActivity1 as this.delayActivity1.Timeout > .... which is allowed when you have code separation. You have to write awful things like ((DelayActivity)this.GetActivityByName("delayActivity1")).Timeout which obviously leads to many problems if delayActivity1 is renamed etc.
3. You can't write any simple line of code.
4. Of course no event handlers.
5. No workflow-level properties - how to pass input parameters on workflow creation if I, for example, need to pass timeout value for one of workflow's DelayActivity.
To be continued... :)
I have yet to encounter a workflow that can't be handled this way.