Somehow missed this post, or at least didn’t get around reading into it enough to form an opinion 
The union of the permissions = roles of all accounts I would say intuitively. Hard to compute in the brain for debugging and ofc has potential for flakey behaviour based on authentication ordering or conflicting role permissions.
IMO it was a bad idea to bind the account to its auth provider.
I always considered the configured provider name (the setting key, not the provider implementation, i.e. UsernamePassword*!) to be something that roughly matches your concept of a “Realm” now (as far as I understood it). At the core maybe a naming issue At least in combination with a RequestPattern. You’d have a NeosBackend, SomeCustomFrontend etc. in your security.authentication.providers settings and then you’d need to query the current account based on the provider. So by connecting the account to the “providerName”, you effectively encode which accounts are applicable in which “realm” (i.e. this is a “NeosBackend” account).
The issue with that I guess is that you easily end up with multiple providers being active for one request (because you need to specify request patterns for each configured provider name, and what if you want to have multiple providers for one “realm”, i.e. multi-factor auth). Hence permissions potentially don’t match the expected (due to the above mentioned ambiguity).
That’s btw something I don’t yet see solved in your proposal - how do you bind a “Realm” to some request patterns? And how is the “Realm” Acme.SomePackage:Default connected to the configured provider Acme.SomePackage:Default? By the name prefix?
Otherwise, if I understand correctly, the basic change is that Account::providerName is renamed to “realm” and made part of the new AccountInterface? Approve 