I think asking the user to give up traffic authentication and confidentiality for a privacy features are best be implemented as a browser extension without this trade-off.
Reading through the code I see very little in the way of webPKI nuance and that's probably not a bad thing. Whatever special webPKI handling browsers do gets overridden by importing a user certificate anyway.
I don't know what will happen when this proxy encounters a host with a bad TLS certificate or when mutual TLS authentication is requested. My best guess is that it will 500 and send an empty page back. Proxies like Squid do the same, though I've also seen proxies generate certificates with the same errors (bad dates, bad domains, etc.) to allow the user to "fix" the problem. I don't think such problems are within the scope of the proxy as long as invalid HTTPS certificates aren't made valid by missing verification.
One additional benefit of this approach is that on a normal computer this system also allows blocking operating system tracking and such, not just browser traffic. Run such a proxy on the network edge and with four it five lines of nftables rules + proxy configuration to force devices to work through the proxy, you can apply the privacy protections on your entire network, or specific hosts if you add exclusion rules to some IP addresses.
On mobile this will be a lot harder because of the prevalence of TLS pinning. Android and iOS are nearly impossible to mitm without root access/jailbreaks even if you do it intentionally. I very much doubt that console and "smart" devices will work with such a system either.
The mitm proxy can inject js into the stream and fake any origin. At least the extension has limits of what it can access, and the code is fixed, unlike a proxy that can say something is anything from anywhere.
I am saying it is a bad thing, in when you put the browser in enterprise certificate mode with a MiTM cert you are disabling security features. All of the problems you have outlined are made worse by the proxy, either by failing open or failing closed.
You are right in that a lot of devices have countermeasures against these MiTM attacks and will not work for this purpose out of the box. This is another reason not to use this pattern for your general purpose tools.
No, but it is absolutely able to inject code which will then be run in the browser.
It does not mean that there is not a single bug, but I do not think it is fair to completely discount this approach. Especially when the alternative is browser extensions which bring their fair share of trouble regarding trust, performance, limited capabilities or even security.
I think mitm proxies should be used for whatever people find them suitable. I don't have a problem with this use case, especially as this is clearly something you will only get working with a moderate understanding of the underlying concepts.
Tools like Privoxy have existed for years and I don't know why you wouldn't trust a proxy over an addon. Just don't set it up for other people who can't make the risk/reward judgement (though the same goes for adblockers and other extensions).
Enforcing Certificate Transparency rules or CAA records, is the proxy doing this?
it's a certificate misissuance, but AFAIK it's not up to the browser.