Thanks for the reply Cyclops,
I can relate to and understand the difficulty of trying to diagnose with minimal detail. 
I'm not so sure I would recommend this approach since it doesn't yet work ;-)
Detecting "In Flight" Processes
To detect a duplicate there are a few assumptions and needs that I have to make for this to work.
The assumption: because I'm using multiple sites I can't depend on the "folio" or SharePoint list id to be unique. For example, all of the lists will have a 1, 2, 3... So I need a unique identifier to use. I get this by parsing out the site name from the "EventDetails" XML field, using a code event in the first process activity. This is a huge assumption on my part because we have restricted control over the infrastructure of the sites being created. So there is expected to be some consistency, and uniqueness to the site names/structure. So, ultimately, the unique id is "Site Name" - "Folio ID"].
The mechanism: I have a SmartBox smart object that maintains the "state" of all processes in flight. I'm only using the "Save" and "Load" methods of this smart object. This smart object has two properties; id, pending flag. The "id" is retrieved from "the assumption". The first time K2 starts a process the smart object "Load" method will error in the smart object so I use an exception rule to catch this and initialize the field to store these properties (id and pending flag). The values received from the smart object method "Load" are stored in process level data fields (both the id and state).
I have a line rule that checks to see if the process is already "in flight". If so, then I immediately terminate the process (blank activity with blank code event). But if this is the first time the process is coming into being then I route the item to the appropriate persons.
Multiple Sites, Single Process (and deployment)?
There are two challenges to using a single process on multiple sites. First, I am using a SharePoint Events Process to start the workflow. I use an Environment Variable in the Connection Settings. This allows me to set these at design time and change them again at deployment. Second, there is the challenge that specific K2 activity wizards present. For example: a SharePoint List Items event asks for a specific site and list. I can't use the same environment variable I used to start the workflow, because that would result in a sister process instance modifying another's list item. Because I am using a SharePoint events process integration to start the workflow, I use the "EventDetails" XML site url for the "SharePoint Site URL" property and the "EventDetails" XML list for the "List Name".
When I deploy, I simply change the environment variable and deploy. There is one caveat (one big gotcha). I must deploy the SAME process over and over again to get to different sites. So in reality, I have the SAME exact code base duplicated in versions, only to achieve multiple site deployment.
Conclusion
If there are better approaches to this solution I would love to hear them!
I have found the solution, or at least, a resolution. The SharePoint event was being raised twice, and in some cases four times. The document library is heavily customized and something in the list, or list template is causing the problem. I don't have a diagnosis, maybe sometime in the future. Just an FYI, the K2 event was NOT registered twice on the list, but the event was being raised twice.
