Password managers are already aware of confirm password fields. There's even an autocomplete attribute to annotate them (use autocomplete="new-password" twice).

Password managers are already aware of confirm password fields. There's even an autocomplete attribute to annotate them (use autocomplete="new-password" twice). Caps lock is a problem even with the ability for a user to see their own password, because they need to take an additional action to unhide their password. Most users won't check, they'll just hit enter. And again, this is something the browser can (and depending on what you're using, already does) do—browsers have shown an icon or tooltip. On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop. And even in the very rare case where you goof with caps lock, there's a forgot password flow that lets you (hopefully) reset your password with the same number of steps as a good OTP flow (which is literally what password reset is). In almost all cases, this is even preferable to adding the complexity (accessibility, L10n, etc) of a "reveal password" toggle OR a confirm password field, because properly implemented it gives the user the chance to use a password manager a second time. It's absolutely bizarre to expect every single web developer to need to know and implement every possible best practice around password handling of this sort, when it could be handled by the (already semantically annotated) GUI control that the user agent implements.