I have just encountered the same problem on Windows XP Professional SP3 (client).
And based on what I have read:
http://msdn.microsoft.com/en-us/library/ms724911.aspx
"If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, the string may not have been stored with the proper terminating null characters. Therefore, even if the function returns ERROR_SUCCESS, the application should ensure that the string is properly terminated before using it; otherwise, it may overwrite a buffer. (Note that REG_MULTI_SZ strings should have two terminating null characters.) One way an application can ensure that the string is properly terminated is to use RegGetValue, which adds terminating null characters if needed."
"RegQueryValueEx will append a missing \0 for type REG_xxx_SZ if there is room, but it will leave it non-terminated if there is no room."
And after a disassembly of mscorlib.dll using Lutz Roeder's Reflector...
I conclude there is indeed a bug in Microsoft.Win32.RegistryKey.GetValue(String) (or RegQueryValueEx depending on how you see it) when the registry value is a REG_SZ stored without a null terminator.
http://msdn.microsoft.com/en-us/library/fdf576x1.aspx
The code for RegistryKey.GetValue() allocates a StringBuilder of exactly the size reported from prior call to RegQueryValueEx, and re-executes RegQueryValueEx. And since the stored string was not null terminated, and the StringBuilder has "no room"... <something happened> that led to random characters being appended (probably reading into a memory location that shouldn't be read).
This is very unfortunate as I will need to write a workaround using PInvoke to get to the values I need as I cannot depend on Microsoft patching the machine my application will be deployed on nor will I be able to deploy my application with the fix.