Their whole "scheme", where ".." can be dealt with as a canonicalizing step BEFORE submitting the path to the OS for actual opening, seems to require refinement when symlinks are involved.

Take a perfectly spherical unix:

    $ mkdir /tmp/hn
    $ cd /tmp/hn
    $ ln -s . foo; mkdir bar; touch baz
    $ ls -l bar/../baz foo/baz foo/../baz
    ls: cannot access 'foo/../baz': No such file or directory
    -rw-r--r-- 1 jepler jepler 0 Nov 28 18:21 bar/../baz
    -rw-r--r-- 1 jepler jepler 0 Nov 28 18:21 foo/baz

Fuscsia-with-symlinks would have some extra hoops to jump through to make rewriting act like POSIX in the case that /tmp/hn is not escaped, which surely you'd want if you went ahead and introduced symlinks.

> which surely you'd want

Nope. I don't want that at all. There's a reason that by default cd goes out of its way to make .. ignore the parent of a symlink.

I think "at the time of writing" implies they're still under consideration, rather than outright rejected due to philosophical differences.

It should be noted that this is not without precedent. Plan9 doesn't have symlinks for example, everything is done using binds. You would be surprised how many complications come up when you add symlinks to path resolution code.