[SalesForce] Are static variables reset per batch during bulk DML operation? (Executing triggers for field updates)

A while back I had a trigger issue where I needed a trigger operation to execute exclusively on the second update or an update after an insert.

So I had some code like this:
Trigger Handler Class

public class FieldUpdateTrigger
{
    private static Boolean _canProcessRecords = false;
    private static Boolean _hasProcessedRecords =  false;

    private static Boolean RecordsAreReadyToProcess { get { return _canProcessRecords && !_hasProcessedRecords; } }
    private static Boolean FieldsHaveBeenUpdatedByFieldUpdate 
    {
        get { return !_canProcessRecords && !_hasProcessedRecords; }
    }

    private static void ProcessRecordsAfterFireldUpdate(List<sObjects> recordsOfInterest)
    {
        //Process the records with values populated by a field update
        _hasProcessedRecords = true;
    }

    public static void ProcessMyExamples(List<sObject> recordsOfInterest)
    {
        if(FieldsHaveBeenUpdatedByFieldUpdate)
        {
            _canProcessRecords = true;
            return;
        }

        if(RecordsAreReadyToProcess)
            ProcessRecordsAfterFireldUpdate(recordsOfInterest);
    }
}

And the trigger would look something like this:
Trigger Code

trigger ExapleTrigger on Example__c (before insert, before update)
{
    if(trigger.isBefore && (trigger.isInsert || trigger.isUpdate)
        FieldUpdateTrigger.ProcessMyExamples(trigger.new);
}

Now everything would work fine, until I started loading data into the Data Loader.

Apparently, it would only process 200 records (a known batch size) and ignore the rest of the records that were inserted.

This was due to my understanding, which must have been uninformed, that every batch (every 200 records) would get it's own execution context. Thus, the _hasProcessedRecords flag would be set to false again, but that doesn't happen.

My quick solution was to reset the _hasProcessedRecords flag when I check to see if fields have been updated by a field update, but I was curious why I had to do that when this should have been reset.

Also, I am curious on any solutions that more eloquently deal with triggers that need values after a field update.