I'm planning to mark this as WontFix, based on the list of consequences. I don't see any need to implement a mitigation for M69.

Dominic, Vadym, do you agree?

Marking as wontfix as indicated. Happy to re-open if you disagree.

Slight correction about saving:
Chrome still parses forms for saving using the old parser (NewPasswordFormParser::Save() is not implemented yet).

So the new parser would currently likely not find the username to be saved. This needs to be fixed for saving, but still won't affect how Chrome behaves in 69.

Another instance: https://www.linkedin.com/: password fields get hints, but usernames don't.

What would happen to a
<form>
  <input type="text" name="username">
  <input type="password" name="password" autocomplete="new-password">
</form>
that is not handled by autofill votes, when the autocomplete attribute is a fake and the user tries to fill the username/password via manual fallback?

The manual fallback would work with the old parser, and also with the new parser after https://crrev.com/c/1108209.

(The piece breaking this for the new parser is the explicit condition in NewPasswordFormManager, which is removed in https://crrev.com/c/1108209. So it's not the parser which causes it but the new filling infrastructure.)

https://www.heraldsun.com.au/ contains a more impactful version of this bug:

The login form has username marked up as autocomplete="email" (and password as current-password). Correspondingly, the new parser does not find the username.

Because this is a login form, this actually results in filling issues: it is not possible to get filling suggestions in the username field (it is still possible to get them in the password field). This particular page has the login form in a cross-origin iframe, so it has been never autofilled, but otherwise this would also mean the difference between being autofilled and not.

This has been fixed by r571937.