Off to a roaring start, the UNIX port on macOS gives me:

Traceback (most recent call last):
  File "test.py", line 6, in <module>
UnicodeError: 

Where test.py is:

import os
from vfs import VfsPosix as Vfs

print(os.getcwd())
v=Vfs('.')
print(v.getcwd())

Looking at the VfsPosix source:

It looks like VfsPosix('.') would try to build a relative path quite naively and end up with:

/home/bob/micropython-work/test/./

And, indeed, if I specify a path like that I get the same UnicodeError.

However:

import os
from vfs import VfsPosix as Vfs

print(os.getcwd())
v=Vfs('/./')
print(v.getcwd())

Produces a similar broken path bug to yours, except it's chopped off the front...

./build-standard/micropython test.py
/Users/gadgetoid/Development/micropython/ports/unix
ers/gadgetoid/Development//micropython/ports/unix

There is something going on here!

Edit: under the hood this just calls the Posix chdir and getcwd.

Since VfsPosix("/some/path") sets the root of the object and doesn't actually chdir into that directory, you might find the following works more reliably:

vfs = VfsPosix()
vfs.chdir(os.getcwd())

Specifying a root to VfsPosix doesn't seem to materially affect how chdir and getcwd work, they don't seem to be relative to that root nor bounded by it. It does completely break getcwd() though since that tries to cut the root path off the front of the returned directory.

Some more info here: #12137

A particular tidbit of that is:

In the intended use of VFS objects via os.mount() (as opposed to calling methods directly as the tests do)

So perhaps there are more bugs in VfsPosix, but also they are broadly worked around when it's used with os.mount().

Right, I saw that VfsPosix() (or what seems to be equivalent, VfsPosix("") or VfsPosix("/")) works reliably in these respects.

I think this bug just manifests when non-empty and non-absolute roots are supplied to the constructor. I did get the impression from my (non-systematic, exploratory) testing that such roots did make a difference to some operations --- for instance that they constrained when a chdir("..") call to the vfs object would work. What I'm more sure of is that VfsPosix(".").ilistdir("/") is rooted in the . directory, not in the filesystem's / directory. Same with VfsPosix(".").stat("/"): it will give info about . not /. And VfsPosix(".").stat("/sub") will give info about ./sub, not /sub.

I agree there are workarounds. But since this seemed to be buggy behavior, that could potentially lead to corrupted data or worse, I thought it should be noted and fixed.