The code for Cwd::cwd() looks like chop(`pwd`) which is rather unpleasant in my opinion

In my opinion as well. Unfortunately there aren't really any less unpleasant alternatives. Unix tracks the current working directory of the process by number (you can think of it as tracking the CWD i-node number or having a handle to opendir() handy -- depending on whether you think like a kernel or a user). So there is no "good" way to tell what you current directory is. Shells usually resort to caching the path used to get to this particular directory because of this.

So /bin/pwd does stat(".") and opendir("..") then stat("..") and opendir("../.."), etc. trying to build a path to the current directory. But you can cd into a directory where you have execute access but no read access. This means that /bin/pwd would fail, except that it is often set-UID to root for exactly this reason.

Unix provides a subroutine, getcwd(), that does the same thing as /bin/pwd. Often, this functionality if provided by fork()ing and exec()ing /bin/pwd and reading the results from a pipe. Sometimes, the Unix supports privileged subroutines so that /bin/pwd can be implemented directly in the subroutine and still succeed more often (it isn't that hard to have a current working directory for which there is no path).

So it would be nice if Cwd.pm had an XS component so that it could call getcwd() on versions of Unix where that doesn't just run /bin/pwd.

Or you can just install a real O/S and avoid this whole mess and just call Win32::GetCwd(). (No, I'm not serious. This suggestion is just as useful as the usual "install a real O/S" suggestion that I still hear too often.)