Be careful using non-alphanumeric field names in SharePoint

I found that there are some inconsistency in internal name generating in WSS 3.0. I encountered with it when receiving en error on checking in a file. SharePoint log file did not reveal the problem as usual :) and I used my custom code to troubleshoot. This is the exception description and a stack trace I received:

at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName, Boolean bThrowException)
at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName)
at Microsoft.SharePoint.SPListItem.get_MissingRequiredFields()
at Microsoft.SharePoint.ApplicationPages.Checkin.OnLoad(EventArgs e)

I started to review code in Reflector and discovered that SPListItem.MissingRequiredFields property is checked on page check in. For this purpose it uses SPFieldLink.Name from SPListItem.ContentType.FieldLinks collection to retrieve SPField object from SPListItem.ParentList.Fields collection for every field which is SPFieldLink.Required=true. In order to get SPField object SPFieldCollection.GetFieldByInternalName() method is used and if SPFieldLink.Name field value is not found as internal name of any SPField then we receive "Value does not fall within the expected range" exception.

In my case I have a field named "Description of Change/New document" which is translated to internal name as "Description_x0020_of_x0020_Change_x002F_New_x0020_Document" but for some reason SPFieldLink.Name field value for this field is "Description_x0020_of_x0020_Change_x002f_New_x0020_Document". Feel the difference in unicode of symbol "/": x002f (small 'f') and x002F (capital 'F'). That gives me two different internal names and I have these troubles. I guess there is inconsistency and there are several functions which generate internal name and these functions produce different result in some cases.

When I recreated my field the problem was fixed for which I do not have any explanation.