Good quesiton, but what is the real question? The key phrase from your question for me is 'business process triggers'. If I may, I think the discussion needs to start from a application layering perspective, or put more specifically 'where do we put our business process logic?'. Before I get on to that let me say this about triggers...
The thing about triggers is... they respond to data centric actions, period. If you view the top to bottom architecture of your Force.com application, its easy to forget your still dealing with the database tier when writing code at the trigger level. If you look at the rich level of API support and an native UI around this database tier. You will soon realise your effectively developing an app on a database schema that is by default open, like it or not. You have to service this way of interacting with your app. Take Salesforce Touch for example, this provides your clients a rich mobile/tablet client for free! Then the new REST API, the list goes on. You only get the benefit of these if you embrace letting your customers / developers access this tier safely and clearly (so good database design is even more important ironically). So when you look at it from this angle, its important to consider carefully any requirements that lead to design patterns, validation rules etc that might impact the use of your 'open database tier'. And don't get me wrong, there are some good reasons to, but you must design firstly for things to be open and discuss carefully what the implications are of over complicating or closing off parts of your database schema interaction.
So that all sounds good, but why do I still find it hard sometimes to implement what I want? Well, if your application is typically "data centric" in its purpose, you'll generally have an easier job. A user interactions, much like Salesforce CRM, are typically tasks surrounding the scope and lifetime of individual records. So triggers, layouts, record types really start to come into their own here. But if you have an application that is in part 'data centric' (for standing / master data) and part 'process/task centric' where does that leave you? Enter SOA...
Service Orientated Architecture and Control Fields? Unless you're solely a data centric application. Your going to have to find a place for your clients (and by 'clients' I am not just talking about human consumers here) to consume / access your business process logic. Having them tweak Control Fields at your schema level may make sense and there is scope for it, if you can work it nicely into the schema. But over use of it, along with having your clients dependent on a deeper understanding of your schema. Will introduce voodoo into your schema and increase the barrier to entry for your application interactions, developer, end user or platform wise. So to avoid users poking around trying to reverse engineer your VF logic, control fields, why not consider exposing a service layer in your applications for such logic?
So OK, how would I implement the code in the question above? Developing a generic Apex solution is really a solution for a problem that I don't think should be solved generically or at the Apex level (see my thoughts below). Generally to much of this approach is teaching your database tier code
about the business processes that should be implemented above it. You should let your business process tier do the driving and expose that as a service for your clients / callers to consume (in addition to those already provided by Salesforce btw!). The trick then is marketing and supporting the strict design, development and consumption internally (for your own client developers, be they VF, mobile or otherwise) and externally of them. Again don't get me wrong we should absolutely fill our triggers with great value add logic, but it should know its place.
Control Fields : Heap vs Custom Field : That said, when taking the Control Field approach, and as I describe above is valid, when it 'fits' with your schema and thus API / native UI experience sensibly. When implementing it I am in favour in the first instance of designing it in into the application schema as a field. This way everyone knows whats going on. Again the schema is open and not declaring it (by managing internally) only leads to frustration, low barrier to entry due to higher complexity (internally and externally). I've also been burnt a few times with Static, initialisation and state carry over, while I'm not 100% sure, for example, I think Batch Apex serialises statics over 'execute' invocations, which can catch you out at times.
Application Enterprise Patterns on Force.com
Here is a diagram i presented at a recent Dreamforce session about Enterprise Application patterns. The sessions slides takes a simple scenario and walks through, what might be described as a 'consolidated' or 'merged' approach typically seen when people start out or smaller applications, and again this approach has its place as well. What I followed this in my session with was a more layered approach using some Application Enterprise patterns along the way. I'm pleased to say it got quite a good reception and has since generated a steady stream of interest (I've got a draft blog posting on it in the working btw). You can find the Github repo here, with more info on the patterns. The slides are here.
NOTE: That Trigger invocation is not shown here, the SObjectDomain class takes care of routing the CRUD events from the triggers to the 'Domain' classes representing the Standard or Custom Object behaviour your application is implementing. This pattern enforces development of appropriate logic for this context. Leaving the Service layer to doing any process level orchestration.