As you note, we already have a system that uses more appropriate cryptography (than a PAKE) to solve this: FIDO.
You've lost me at mTLS here. At some point it starts to feel like we're advocating for security protocols just so we can fit them all in somewhere.
That was a bit tongue-in-cheek, sorry. I've worked in mTLS shops and it's definitely not practical for the public Internet.
Ultimately, I think the practical solution to homoglyphs is in the presentation layer, whether it be displaying different scripts in different ways, warning when scripts are mixed, or some other kind of UX rather than protocol change. The only protocol change I can think of to address them would be to go back to ASCII only (and even that is more of a presentation issue since IDNs are just Punycode).
mTLS is going to be a problem soon, arguably bigger than this lifetime reduction. Most server certs today have clientAuth EKU and can be used for mTLS. That stops next year.
It took me awhile to dig up evidence for this, but the closest I can find is that subordinate CA certificates will no longer be allowed to have id-kp-clientAuth EKU [1], however this restriction does not apply to leaf certificates.
[1]: https://googlechrome.github.io/chromerootprogram/#321-applic...