Thank you for the reply.

* As already stated, I believe that Python 3
  is not affected by this problem; certainly,
  version 3.5.2 does not seem to be affected,
  as per my ad hoc testing.

* Very many programs are targeted to Python 2.7,
  and probably will be for quite some time.

  Without my patch, `python' (2.7) itself breaks
  them as described; yet, with my patch, these
  programs will just work (without intervention).

  It seems to me that this patch isn't a change
  in a feature, but is rather the overdue
  implementation of promised behavior; the
  file system is what matters, not the host
  operating system, which has hitherto been
  conflated with the file system.
  
  That is, this patch is a bug fix.

* I'm not sure how a test could be written to
  handle this situation.
  
  I suppose that by default, such a test could
  be skipped with a warning; a user could be
  required to set up a relevant mount point,
  and then to signal the testing infrastructure
  to use it.

---------------

* With regard to the form of the patches, my
  intention is that they be introduced into
  the history severally, with the commit
  messages and other metadata as specified.
  
  It would probably make most sense for these
  commits to be the ancestors of a merge commit
  that provides the sole reference to this
  tracker issue.

  For instance, the most correct and useful
  application of the patch series is given
  by the following:

    $ hg pull --branch 2.7 # This must pull in something new for the rest to work.
    $ tip=$(hg log --limit 1 --template '{node}' -r tip)
    $ hg update -c -r 59260b38f7cd4a2ae66928de5227798524006e64
    $ hg import /path/to/pep-235-on-posix.patch
    $ hg merge -r "$tip"
    $ hg commit --message "Issue #28670: Implement PEP 235 on every POSIX system, and clean up the C code for \`import'"

  That produces a single commit whose message supplies
  the usual dearth of information, but whose ancestral
  history captures the rich details.

  It should be noted that `hg bundle' and `hg unbundle'
  could be used to import more directly the proper
  pre-merge history, albeit at the expense of the
  human-readability of the "patch" file.

  That is to say, I'm underwhelmed by the way you guys
  are managing this project's history. Despite all of its
  faults, Mercurial is still being underutilized.

* I could split the original patch file into 3 separate
  patch files, but what should I do with the metadata?
  If each separate patch were to contain its own metadata,
  would the code review tool still choke? I suspect it would.

  What's the point?

  The original file itself is perfectly readable, and you
  can simply review the diffs after applying them within
  your repo, anyway. Ironically, the very point of having
  multiple changesets is to make digesting the changes as
  easy as possible---not only now, but far into the future,
  when you're simply looking at the graph of the history!