If %AppData%\.minecraft is a symlink to a network share, the Launcher sometimes changes subdir names to uppercase. For me, this caused the game to freeze when I clicked a button in the menu, because the click sound could not be loaded. The debug log said:

Client> Error in class 'CodecJOrbis'
Client> Unable to acquire inputstream in method 'initialize'.
Client> ERROR MESSAGE:
Client> minecraft:sound/random/click.ogg

Which subdirs end up with uppercase names seems random, for example, multiple tries with a fresh .minecraft lead to the following combinations:

.minecraft/assets/SOUND/MOB
.minecraft/assets/sound/MOB
.minecraft/assets/sound/mob
.minecraft/ASSETS/SOUND/mob

This was already reported twice, as MCL-1001 and MC-28302. Because it happens only with a symlink to a network share, it was assumed it must be the Windows symlink or the network server which happen to mangle the names.

However, I analyzed Windows API calls of the Launcher using ProcessMonitor (1), and found evidence that the name mangling happens in the Launcher. The Launcher doesn't let the OS follow symlinks, but handles them by itself, and this handling sometimes introduces uppercase names.

I used ProcessMonitor to watch javaw.exe when starting the Launcher with an empty .minecraft directory, and I compared what happens when .minecraft is a symlink and when not. Windows has an API CreateFile() (2), which is used to open and/or create files and directories. This function would by default follow a symlink, returning a handle to the target of the link. That would make the link transparent to the application. But this function can also be called with the flag OPEN_REPARSE_POINT, which causes it not to follow a symlink, but to open a handle to the symlink itself, making it possible to modify symlinks, check where they point, etc.

The Launcher calls CreateFile() with the OPEN_REPARSE_POINT flag, and if it hits a symlink, CreateFile() is called again with a translated path. Sometimes, this translations introduces uppercase names.

I attached log files of my monitoring sessions, they can be viewed with ProcessMonitor, and I made a screenshot, pointing to some log entries showing where a bad name translation happens. I've also attached a Launcher debug log, but this doesn't reveal whether a symlink is involved or not.

(1) http://technet.microsoft.com/sysinternals/bb896645.aspx
(2) http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx