Chrome not using hosts file for IPv6 addresses since v73

After a recent Chrome update to v73, Chrome no longer uses my hosts file for IPv6 addresses. I have an entry like:

::1    some-project.test

Trying to go to https://some-project.test results in ERR_NAME_NOT_RESOLVED. If I change the entry to 127.0.0.1, the hostname resolves.

There's no problem with my hosts file entry. It's worked fine for months on previous versions of Chrome. I can ping some-project.test. Firefox works fine. I can even run a proxy like Fiddler and Chrome can access it that way. I just can't use Chrome directly.

Any suggestions for working around this?

Update: It seems dependent on the network I'm connected to. After moving from a public WiFi network back home, this is working again. I'm not sure how that's possible... shouldn't the hosts file override anything in DNS? And, shouldn't Chrome be using the system resolver anyway? Everything else on the system does and works fine.

Update 2: Back on home wired Ethernet... broken again. The problem is intermittent.

There is a know bug in Chrome which might be responsible for your problem:
Issue 530482: Can't reach private IPv6 hosts on networks without global IPv6 connectivity.

The discussion in the bug report clarifies that Chrome launches an IPv6 probe to determine if there is IPv6 support, by checking with a remote address. If that IPv6 probe fails, Chrome will mask out any other IPv6 results, in effect disabling IPv6 and ignoring it forever.

The explanation is then that if IPv6 support is sketchy on the network, so that this single initial IPv6 probe done by Chrome fails, Chrome will just disable IPv6 resolving totally, including local IPv6 resolving from the hosts file.

A workaround mentioned is:

Add a network route to 2001:4860:4860::8888. Doesn't have to actually be functional (could just drop requests to it). As long as Chrome can connect a UDP socket to the address, it will pass the heuristic checking IPv6-connectivity and allow AAAA DNS queries and IPv6 resolve results.

Other more limited workarounds are mentioned at the end of the bug report.

The bug report dates from 2015, but was still alive in May 2019, so it may perhaps be currently in process.