It seems that the new Summer'13 update enforces you to work with 18 character ID's always. For example, this happens in apex:

Id Id15 = string.valueOf(Id18).substring(0,15);
System.AssertEquals (Id15,Id18);

Pre-Summer that assertion fails, as Id15 is the 15 character Id and Id18 is the 18 character Id.
In our custom code many times we use Custom Setting and Custom Labels to avoid hardcoding recordtypes, profiles and other "constant" values. We usually worked with 15 character Ids as Salesforce (SOQL) sometimes returns 15 and other times returns 18 character Ids.

Now it seems the ID type always returns 18 character, if you do something like this the assertion is true:

Id Id15 = '012200000005byN';
System.AssertEquals (Id15,'012200000005byNAAQ');

As this is happening now with the Summer'13 but not happening before with Spring'13, this invalidates many coding.

We found this problem as Salesforce triggered a deep system error like this Salesforce System Error: 1619326252-34083 (1564369920) (1564369920) trying to compare a SelectOption loaded with record types with a Custom Settings String Id Stored.

This is a really weird annoyance. You can take a workaround working always with ID type instead of storing Ids into Strings, and always working with 18 character Ids, wether you hardcode Ids into apex and formulas (not a good approach) or you use custom setting and labels to store the ids.

Hope this helps... I lost all morning trying to figure out this.