Able to reproduce the issue on reported chrome version 66.0.3333.0 using Windows 7/10, Ubuntu 14.04 and Mac 10.12.6. As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking it as Untriaged.

Thanks!

Thanks for the report. So far I cannot reproduce this issue, on Mac with Canary version 66.0.3334.0. Let me describe what I did, and perhaps you can correct me in where I departed from your steps:

(1) Go to http://1.chromium-test1.appspot.com/testing/psl-matching/login.
(2) Type the username "a" and password "p" in that form, submit and accept to save that.
(3) Go to http://2.chromium-test1.appspot.com/testing/psl-matching/login
(4) Type the username "a". Accept Chrome's suggestion to fill the password from step (2), or ignore it (did not matter in my case).
(5) Type a different password ("bcd") in the password field, overwriting what Chrome filled if needed.
(6) Hit Submit.

After step (6) I see a prompt to save the new password, not to update the one from step (2).

Attaching a screencast of #4.

Deleted: 806530.mov 4.8 MB

	806530.mov 4.8 MB View Download

Everything works correctly as long as the passwords are different from the beginning like in the comment #4. Then if you change one of them then only the password for the exact origin is updated.
The fun starts when you have the same password stored for example.com and something.example.com. If you log in on one of them with a new password and click "Update" in the bubble then both are updated together.
I think this is exactly what happened in this bug. Chrome had a wrong credential for something.example.com. Otherwise, it would not fill it there.

Now to the question about what's correct. I think we want to keep the current behavior to optimize for the cases like facebook.com/m.facebook.com. On the other hand, we may let user to disambiguate this situation through the UI. We need to discuss it on the team.
Nevertheless, there is a simple work around as of today. Just delete the wrong credential before loading the web form.

Here I see the question about updating, not saving the password, even if the passwords are different, but the username is the same. 
Maybe it matters if one of the subdomains is actually a root domain (example.com)? If you leave it as is, I'd suggest to ask the user whether he/she wants to save a new password (case of different passwords for different subdomains) or to update the password / ignore the operation (case of facebook.com vs. m.facebook.com). Thanks!

Are you saying that you have two credentials for example.com and something.example.com with different passwords? Updating one of them overwrites another one?

Yepp, in my case what happens is just that, for some reason.

Could you double check in chrome://settings/passwords that the passwords saved(!) are indeed different?

Just re-checked with Google Chrome Version 66.0.3340.0:
1. I opened chrome://settings/passwords. At this time, both password fields for example.com and something.example.com contained the password from example.com.
2. I went to something.example.com, logged out, logged back in. Chrome asked whether to update the password. I clicked Update.
3. I opened chrome://settings/passwords again. Now *both* example.com and something.example.com entries contain the password for something.example.com.
I acknowledge this is comfortable for multi-purpose domains such as Facebook, but at least I believe it should warn if it does update the password for several subdomains at once. I.e., "I'm gonna update several entries in your passwords list. Are you sure?" Something like that.

In this case we actually want you to update the password for something.example.com because it's incorrect. Thus, we don't want to scary the user away.
As a workaround you could delete the wrong credential for something.example.com.