Take a look at Triggers and Order of Execution. What you observed is the expected behavior.

Here are the relevant steps.

(3) Executes all before triggers.

(6) Executes all after triggers.

(9) Executes workflow rules

(10) If there are workflow field updates, updates the record again.

(11) If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.

Note: The before and after triggers fire one more time only if something needs to be updated. If the fields have already been set to a value, the triggers are not fired again.

Followed by the following statement about Trigger.old.

Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made.

With the following example:

For example, suppose an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

So, in your case the following occurred:

1. Execute before update: Different.
2. Execute after update: Different.
3. Workflow rule update.
4. Execute before update: Different, because of exception to the rule.
5. Execute after update: Different, because of exception to the rule.

Take a look at Triggers and Order of Execution. What you observed is the expected behavior.

Here are the relevant steps.

(3) Executes all before triggers.

(6) Executes all after triggers.

(9) Executes workflow rules

(10) If there are workflow field updates, updates the record again.

(11) If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.

Note: The before and after triggers fire one more time only if something needs to be updated. If the fields have already been set to a value, the triggers are not fired again.

Followed by the following statement about Trigger.old.

Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made.

With the following example:

For example, suppose an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

So, in your case the following occurred:

1. Execute before update: Different.
2. Execute after update: Different.
3. Workflow rule update.
4. Execute before update: Different, because of exception to the rule.
5. Execute after update: Different, because of exception to the rule.

Take a look at Triggers and Order of Execution. What you observed is the expected behavior.

Here are the relevant steps.

(3) Executes all before triggers.

 

(6) Executes all after triggers.

 

(9) Executes workflow rules

(10) If there are workflow field updates, updates the record again.

(11) If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.

Note: The before and after triggers fire one more time only if something needs to be updated. If the fields have already been set to a value, the triggers are not fired again.

Followed by the following statement about Trigger.old.

Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made.

With the following example:

For example, suppose an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

So, in your case the following occurred:

1. Execute before update: Different.
2. Execute after update: Different.
3. Workflow rule update.
4. Execute before update: Different, because of exception to the rule.
5. Execute after update: Different, because of exception to the rule.

Take a look at Triggers and Order of Execution. What you observed is the expected behavior.

Here are the relevant steps.

(3) Executes all before triggers.

(6) Executes all after triggers.

(9) Executes workflow rules

(10) If there are workflow field updates, updates the record again.

(11) If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.

Note: The before and after triggers fire one more time only if something needs to be updated. If the fields have already been set to a value, the triggers are not fired again.

Followed by the following statement about Trigger.old.

Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made.

With the following example:

For example, suppose an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

So, in your case the following occurred:

1. Execute before update: Different.
2. Execute after update: Different.
3. Workflow rule update.
4. Execute before update: Different, because of exception to the rule.
5. Execute after update: Different, because of exception to the rule.