Indeed, if I apply this patch:

```
diff --git a/Lib/http/server.py b/Lib/http/server.py
index 47a4fcf9a6..de995ae4b9 100644
--- a/Lib/http/server.py
+++ b/Lib/http/server.py
@@ -1246,6 +1246,11 @@ def test(HandlerClass=BaseHTTPRequestHandler,
     """
     ServerClass.address_family, addr = _get_best_family(bind, port)
 
+    def server_bind(self, orig=ServerClass.server_bind):
+        self.socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 0)
+        return orig(self)
+    ServerClass.server_bind = server_bind
+
     HandlerClass.protocol_version = protocol
     with ServerClass(addr, HandlerClass) as httpd:
         host, port = httpd.socket.getsockname()[:2]
```

And then run `python -m http.server`, it binds to `::` but responds on `127.0.0.1` on Windows:

```
~ # python -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ... 
::ffff:127.0.0.1 - - [05/Jan/2020 14:48:09] "GET / HTTP/1.1" 200 - 
```

I think the solution is to add a patch similar to that until Python has a socketserver that supports dual-stack binding. See related issues issue25667, issue20215, issue36208, issue17561, and issue38907.

In fact, since issue38907 captures more concretely what I believe is the main issue here, I'm going to use that issue to address the concern. If Windows is able to bind dual-stack to IPv6/IPv4, I believe that would address the compatibility concern raised herein.

I'm going to mark this as a duplicate, but if you believe there is another issue at play here, please don't hesitate to re-open or comment and I can.