Windows – Symbolic Link Directory (mklink /D) The system cannot find the path specified

you should use cd with -P option to do that.

from man pange:

 -P     Handle the operand dot-dot physically; symbolic link components shall be resolved before dot-dot components
              are processed (see step 7. in the DESCRIPTION).

small test to show how does it work:

kent@ArchT60:/tmp$ ls -ld /opt/google/picasa/
drwxr-xr-x 3 root root 4096 Aug  5  2010 /opt/google/picasa/

kent@ArchT60:/tmp$ ln -s /opt/google/picasa/ cdLink
kent@ArchT60:/tmp$ ls -l cdLink
lrwxrwxrwx 1 kent kent 19 Nov 15 21:23 cdLink -> /opt/google/picasa/

kent@ArchT60:/tmp$ cd -P cdLink
kent@ArchT60:/opt/google/picasa$ pwd
/opt/google/picasa

kent@ArchT60:/opt/google/picasa$ cd /tmp/cdLink
kent@ArchT60:/tmp/cdLink$ 
kent@ArchT60:/tmp/cdLink$ cd -P ..
kent@ArchT60:/opt/google$ 

i think the example above showed what you are looking for.

Three things:

1. don't use symbolic links unless absolutely necessary, because by default you need to be admin to use them. If you only want to link dirs locally, use Junctions, which are supported by a default restricted user as well.

2. Try to replace software which doesn't support long Unicode file names, which is possible pretty often. Those long file names are around ever since NTFS and Windows NT, so software simply should support it and many frameworks/runtimes like Java do so out of the box. Software which is intended to copy things around or back things up, which doesn't support long file names, is pretty much broken and surely has other serious limitations as well, especially in case of backups. Think of things like permissions, handling different links and file types properly, Alternate Data Streams etc. One needs to be careful.

3. The reason for your actual problem seems to be differences in symbolic links vs. Junctions or maybe differences in how the paths provided by the shell are parsed:

C:\Users\tschoening\Documents\test\target>mklink /J "[ target ]" "../src/{[ murks ]}"

Verbindung erstellt für [ target ] <<===>> ../src/{[ murks ]}

C:\Users\tschoening\Documents\test\target>cd "[ target ]"

C:\Users\tschoening\Documents\test\target[ target ]>cd ..

C:\Users\tschoening\Documents\test\target>

As you can see, accessing "[ target ]" this way works, while the following doesn't and generates the same error like you have, only in German:

C:\Users\tschoening\Documents\test\target>mklink /D "[ target ]" "../src/{[ murks ]}"

symbolische Verknüpfung erstellt für [ target ] <<===>> ../src/{[ murks ]}

C:\Users\tschoening\Documents\test\target>cd "[ target ]"

Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.

C:\Users\tschoening\Documents\test\target>

At least I don't see any other difference than /J vs. /D in my test, but I might be missing something of course. So I suggest repeating your test using Junctions yourself.

Some additional interesting thing I just recognized: Opening the created symlink with the above syntax in cmd.exe and Windows Explorer directly fails, but it succeeds in Link Shell Extension. Have a look at the following screenshot, which is showing the relative path. Clicking "Ziel öffnen" opens a new Windows Explorer folder showing the link target. Looks like Link Shell Extension is interpreting / itself and might provide \ to the underlying Windows API? Something which Windows itself isn't doing, but simply using / as are stated in the link itself, which is wrong for paths. So as @Seth already recognized, the / itself is the problem with the symlinks.