MOSS/SharePoint ItemUpdated() & ItemUpdating Events Not Picking Up Content Type Metadata

Overview:
We recently hit a funny on an Event Receiver in MOSS. It's unconfirmed as to wether it's a bug or not but in my opinion is. It was specifically related to the ItemUpdated() event not finished updating content type values when the event is fired (so effectively the item has not updated when the term "ItemUpdated" implies that it has).
Here is the MSDN Forums discussion related to this.

Business Requirements:
- Have a Document Library with differing content types attached (CTypeA, CTypB, etc.)
- Allow users to create new items in the doc lib for each content type
- Depending on the content type update certain content type fields when the file is saved or edited. For example if it is a "Leave Application" then update the "NumDaysLeft", if it's an "Expense Form" then update the "Total Expenses" field.

What Was Done:
An event was attached to the EventUpdated() event to update the relevant fields. There was code sitting in this event that checked the Content Type and would react accordingly:

if (properties.ListItem.Fields.ContainsField("LeaveApplicationID"))
{
// do leave application stuff
}
else if (properties.ListItem.Fields.ContainsField("ExpenseFormID"))
{
// do expense form stuff
}

Symptoms:
- The code
properties.ListItem.Fields.ContainsField("ExpenseFormID")
did not pick up the field. It would return false for the content type "Expense Form" even when one was selected.
- This error was not consistent, some of the time it would work. It appears that in the background the content type information was still being updated whilst the ItemUpdated() event was fired.
- When a debugging break was put on the listItem.ContentType MOSS would return the default content type

Workarounds:

Workaround ItemUpdated() event:
Credit to MKeeper this was his solution. Thank you.
I put a counter in code as well just in case the item never checks in.

int counter = 0;
while( (item.File.CheckOutStatus != SPCheckOutStatus.None) && (counter != 6) )
{
// sleep for 2 seconds and try again
System.Threading.Thread.Sleep(2000);
counter++;
}

Workaround ItemUpdating() event:
Dont use the properties.ListItem.Fields.ContainsField("ExpenseFormID") method in the API. The lookup field that I use "ExpenseFormID" in the edit form was unique to the "Expense Form" content type. "ExpenseFormID" did not exist in any of the other content type it was ONLY in the "Expense Form" content type.
ItemUpdating() works well as it is synchronous so the items are updated by the time the user gets back to the list view after having hit the "OK" or "Check In" button on the edit form.

Check on the existance of "ExpenseFormID" in the AfterProperties object (see code snippet).

if (properties.ListItem.AfterProperties["ExpenseFormID"] != null)
{
// it is safe to use "ExpenseFormID" and the content type is "Expense Form"
}
else
{
// not "Expense Form" dont use "ExpenseFormID"
}