homepage

Since many of os functions were polymorphic in its first argument (path or fd), the logical continuation is to add a (path, dir_fd) pair as yet one case of this argument. In any case dir_fd is incopatible with fd. This simplifies the code of certain functions which takes patch and dir_fd and pass them to lower level without changes, or that use same patch and dir_fd in calls of several functions. This freely adds support of dir_fd to many functions, such as os.path.isdir. This solves the problem of naming multiple dir_fd arguments (src_dir_fd/dst_dir_fd looks ugly). This saves a pre-3.3 signature of some functions, which will facilitate the use of decorators and improve compatibility with alternative implementations.

I dislike this and always have. I think it would look ugly and be obnoxious to use.
If you really think you can get this in for 3.3, you will have to bring it up with Georg. I think your chances are about zero.

Correctly avoiding symlink attacks, which is the whole reason the POSIX *at variants and the dir_fd parameters were added, is not trivial in general. os.fwalk and shutil.rmtree went through many iterations before reaching a state where they should successfully avoid the problem.
Simply passing a (path, dir_fd) 2-tuple instead of a string and calling it done is highly unlikely to produce a secure result, thus rather missing the point of the exercise.