Is this referring to HTTP authentication? (when the browser prompts a modal dialog to authenticate to server or proxy).

This doesn't seem like something we could do safely given how the scoping of the auth realm.

I'm talking about anything done via the password autofiller managed via chrome://settings/passwords, though HTTP auth could be excluded if it would be a problem.

Chrome should be able to offer filling across subdomains, provided they share the eTLD+1 suffix.

Example:
(1) Save a dummy credential on http://1.chromium-test1.appspot.com/testing/psl-matching/login
(2) Go to http://2.chromium-test1.appspot.com/testing/psl-matching/login, click the username
(3) Chrome lets you fill the pair stored in step (1).

Does this address your use-case?

As a concrete example, my password manager has different entries for the following domains, even though each entry has the exact same username and password:

csueastbay.edu
bb.csueastbay.edu
horizon.csueastbay.edu
proxylib.csueastbay.edu

In case this was a recent feature, I cleared all csueastbay password entries and logged back into them, one by one, to re-store the password.  It still stores a separate entry for each domain.

I do use kwallet as the backing store for my passwords.  Could that be the problem?

Thanks for the reply, and also for the important observation in the last sentence.

Indeed -- kWallet is the only password storage backend which we don't support for sharing credentials between subdomains with same eTLD+1.

This is not optimal, but years ago when we decided between implementing this last part, and migrating all kWallet-backed instances to a uniform LoginDatabase, we decided to invest in the latter only. Sadly, it's moving slowly, being tracked in bug 571003.

I'll duplicate this feature request against bug 571003, because once bug 571003 is solved, the feature request will be fulfilled.