as the connectivity-check is enabled in /e/ too (it’s useful after all) it’s certainly affected. Mullvad links their docs how to disable it (
adb shell settings put global captive_portal_mode 0)
Up the same alley (“connections outside the vpn”): the private-dns feature uses the non-vpn Connection for probing requests if dnsovertls is filtered. If a users wants to avoid this, the private-dns feature can’t be used as is, see this bug. I guess mullvad disables the private-dns and uses the network (read: vpn) supplied dns, though I haven’t checked docs on this.
I’m not very alarmed about both issues. What is leaking is hard to give an observer any additional knowledge or an arbitrary destination website to get your real IP if connecting through a vpn. It allows “denial of service” if endpoints are forbidden, but needs compliance of endpoints (Google, /e/) for any correlation advantage.
… such an de-anonymization attempt would require a quite sophisticated actor, most of our users are probably unlikely consider it a significant risk.