> In other words, if someone wants to be a malicious actor (say, they had a "legitimate" package from versions 1.0 to 2.1, but 2.2 contains a trojan), they can do it even with 2FA.

That's a different threat model. We're talking about account takeover, which is a separate risk from maintainers going rogue. 2FA addresses the former; the latter is difficult to address in the general case. Nevertheless, it's something that people are tackling both with static analysis and "reputational" schemes.

> it adds an undue burden developers, particularly brand new ones that just want to "publish their package," have to deal with

You're right, which is why it's not mandatory for everyday users. The decision to enable 2FA for "critical" packages is a practical and calculated one: most critical packages are maintained not by brand new PyPI users, but by seasoned engineers who understand their centrality to the ecosystem and the importance of measures that secure their work. There's no current plan to make 2FA mandatory for every single user; the threat model doesn't justify it.

> including doxxing yourself and providing a real phone number, you would 100% be deterred.

I'm not sure what this has to do with PyPI. PyPI does not and has never supported SMS 2FA. This was an intentional design decision on my part.

The only supported 2FA methods are TOTP and WebAuthn, both of which can (and do, by default) preserve nominal anonymity. No phone numbers are involved.