Have you gone through alllll the trouble of setting up the new Workflow Manager and Service Bus bits to get SharePoint 2013 workflows happening? And then you installed the Office 2013 tools for Visual Studio 2012? Finally, you opened a new project, created a new workflow, right-click-deployed it to see that it works on the site, made a change back in Visual Studio, redeployed, and didn't see the updated workflow?
Yeah, me too.
Turns out, there's a bug in Visual Studio that doesn't cycle the proper services upon a re-deployment. At first, I just figured I just sucked at workflow and didn't have something configured correctly. Then, after dealing with this for two days, I began to suspect that something was wrong. I IISRESETed; nothing. I cycled the timer service; nothing. I had to reboot to see my changes! Sometimes you feel like you're losing it with technology. And then sometimes...some very rare times...there's actually a bug in Visual Studio that makes you feel much better about yourself. You can read about it on Connect here.
Click the "Workarounds" tab on the page above and follow the one posted by Mike Hatheway on 5.10.13. Basically, you set your pre-deployment command in the WSP project in Visual Studio to automatically kill the vssphost5.exe process upon pushing your updated workflow to the local farm. There's not a ton out there about this little guy, but judging by the name, I'm guessing it's similar to Cassini and IIS in that it's a process that helps Visual Studio do some of its deployment and debugging magic with SharePoint.
Here's to exploring that latest in Visual Studio / SharePoint workflows!