The following might be useful:

Between step (2) and (3), open a new tab with chrome://password-manager-internals/

Then share the output on that site after revisiting the site in step (3).

Another relevant question: Is this limited to certain platforms or happening on all platforms?

The passwords startup failure seems to mostly be affecting M57 desktop clients right now. The quantity is trending down significantly, but was very high over the last month. 

Should we raise the priority of this?

I would be curious to see the modification date of the "Chrome Safe Storage" entry in the Keychain Access application.

There's a discrepancy in the data I'm looking at; Sync.DataTypeStartFailures is reporting a very high number of failures for the Passwords type relative to the number of PasswordManager.LoginDatabaseInit failures reported. The sync failures seem to mostly be on Windows and OSX, whereas the PasswordManager failures are on Android. I am going to investigate this further. 

The discrepancy I noted in #8 might be explained by the rollout of un-encrypted passwords metadata; the timelines and milestones seem to match.

What would that mean? That somehow the un-encrypted passwords metadata getting synced is causing failures in starting up the sync datatype?

Would that break passwords autofill?

Nevermind all that, we just discovered that the large number of reported Sync.DataTypeStartFailures are the result of a very small number of clients(10) spamming the metric. Most users are un-affected and the unencrypted passwords rollout is just a coincidence. 

Phew, okay :)

So, does that put us back at square 1 in terms of the original bug report?

Pretty much. There's the known version mismatch failure, which is probably the cause of most of the reported problems. 

The way to triage the problem when a syncing user apparently lost the passwords on a device but they are still on passwords.google.com:
we need chrome://sync-internals/ (also covered by PasswordManager.PasswordSyncState) and value of PasswordManager.LoginDatabaseInit in chrome://histograms/ (the latter isn't applicable to Linux).

If PasswordManager.LoginDatabaseInit isn't a success then the value describes the type of failure of the storage backend. The most popular is "Incompatible current version" that means the user downgraded Chrome version somehow. We can recommend to upgrade Chrome in this case. A universal advise for PasswordManager.LoginDatabaseInit failures is too delete the database file manually. Then the passwords will be synced down from the server.

If PasswordManager.LoginDatabaseInit is a success then the only case I know so far is on Mac if the encryption key was somehow overwritten in the Keychain. In that case the modification date of "Chrome Safe Storage" should correspond to the date when the problem showed up. We still don't know why it happens. But when it happened, the way to go is to delete the password database file manually.

The storage is in '<Profile Path>/Login Data'.

One thing to add to the above instructions(which I followed to fix my passwords db being a version ahead): make sure that chrome completely restarts after deleting the passwords db. It's common for it to continue running in the background, which prevents re-creation of the database. 

Thanks Vasilii and Patrick. Given that we don't have any more specific reason to believe there's a broader issue here, and that we've provided advice to give to users, should we close this out as Fixed?

pnoland@, how did you get into the state of the DB being a version ahead?

I inadvertently ran an official release build of my local enlistment. Probably not that common in the wild?

I think so. I'm fine with closing the bug.

Reading #14, it seems like in both scenarios, the solution is to delete the passwords db and restart chrome. Would it make sense to do this automatically for users? So they don't get stuck and have to do things manually?

We can do it for the sync users cautiously

Marking this bug as Fixed, per the discussion in #16-21.

I filed Issue 730625 to follow up on automatically fixing things for syncing users.