Unless a config entity always uses or subclasses ConfigEntityStorage, there is no way to be sure that it supports overrides, dependency management, scalable entity queries, etc.
Enforce tight coupling between ConfigEntities and ConfigEntityStorage
Remove KeyValueConfigEntityStorage and associated tests
User interface changes
Trying to use a storage class that does not extend ConfigEntityStorage will now throw a ConfigEntityStorageClassException exception.
Content and config entity info is currently collected at the same time, and also has the same _alter() hook.
Configuration entities have a locked storage backend (must always be configuration storage, you can't swap it to something else and expect it to work). There's also going to be more divergence down the line.
So we should split the discovery and the alter to make it clear these are different things, and enforce the storage restriction on the configuration entities.
This would also solve issues likewhere there's no differentiation between the two.