How would that work? A forked/execed subprocess somehow forcing chdir() in it's parent?

Guessing it isn't terribly useful.

Guessing it isn't terribly useful.

You guess correctly. The issue is that POSIX states that

    ... all of the standard utilities [...] shall be implemented in a manner
    so that they can be accessed via the exec family of functions as defined
    in the System Interfaces volume of POSIX.1-2008 and can be invoked
    directly by those standard utilities that require it (env, find, nice,
    nohup, time, xargs).

Note however that /usr/bin/cd isn't completely useless: It has the same diagnostics (error message and exit code) as the command, so `env cd $FOO` is a way to check if you can change to that directory without actually doing it.

I too don't see how it is useful but it's certainly a thing. The Solaris implementation looks like this:

    #!/bin/ksh -p
    # ...
    cmd=`basename $0`
    $cmd "$@"

I just noticed that the what(1)-string (I haven't seen on of those for a long time) references "alias.sh", perhaps this is a clue?

    #ident  "@(#)alias.sh   1.2     00/02/15 SMI"

Were builtins actually aliases in an early shell? I still don't understand how this works though.

That's a funny implementation. It would end up being an infinite loop for any command that wasn't a builtin, or didn't have an identically named thing higher up the PATH. Like if you renamed it from /usr/bin/cd to /usr/bin/mycd.

On my Mac, it's

  #!/bin/sh
  # $FreeBSD: src/usr.bin/alias/generic.sh,v 1.2 2005/10/24 22:32:19 cperciva Exp $
  # This file is in the public domain.
  builtin `echo ${0##*/} | tr \[:upper:] \[:lower:]` ${1+"$@"}