Windows Workflow 4 is a major rewrite of the library. While it has the same goal, to provide a modeling language for long-running tasks, there are some significant differences coming out of what is essentially a complete rewrite.
First a note on backwards compatibility. There is none. You can use the Interopt activity to call a WF3 workflow from WF4, but there are significant restrictions. For example you cannot use WF3 Send and Receive activities, nor can you suspend the workflow or invoke other workflows.
Rewriting a WF3 workflow in WF4 can be a daunting task. WF4 uses pure XAML to define workflows, which makes them much easier to programmatically generate but also means you lose the ability to leverage Code activities. State Machine workflows are not supported in WF4, so anything based on them will have to be redesigned. The way it handles errors is also significantly different, hence the reason the Suspend and Terminate activities are gone. Many of the other activites also changed name and/or semantics. Matt Milner’s change list from July seems to the most up to date.
If you are new to Windows Workflow and don’t have anything invested in the legacy version you are in for a treat. WF4 claims to greatly simplify hosting workflows, managing data, and creating custom activities. Gone is the requirement to use dependency properties to flow data between activities.
A key selling point for Windows Workflow 4 is its integration with Windows Communication Foundation and Windows AppFabric. Microsoft envisions developers building message passing applications in a “WCF on the outside, WF on the inside” style with Windows Server AppFabric providing the hosting.