Abstract entity status out to an interface

Can I ask where this impetus for fracturing EntityInterface into little tiny bits is coming from? First IdentityInterface, then Access(ible)Interface, now this.

AccessibleInterface and AccessInterface did and do not have anything to do with entities. AccessibleInterface is a generic interface that was namespaces as being for typed data only, and AccessInterface was for routing, but its namespace made it look like a generic interface.

The reason I want to split up the entity interfaces is that we have put all kinds of functionality on them, but that not all entities use it. Technically the entities conform to the contract, but they don't actually do anything with it. In case of contact_message entities, calling $entity->save() will actually break, because the method implementation assumes a storage controller, which is never configured for good reason. However, as EntityInterface requires entities to implement CRUD methods, there is no way of knowing whether such entities can be saved at all without checking the annotation. As such, I would argue this is a broken implementation of a contract.
On the other hand we put things on ConfigEntityInterface that may not be limited to config entities, such as statuses. Most config entities use it, but not all, such as taxonomy_vocabulary, which is a broken contract implementation. On the other hand some content entities could benefit from it as well, such as node.

So nobody agrees with me that it's just downright idiotic that we force entities to pretend they offer particular functionality, while they actually don't? Having enable(), disable(), status(), and setStatus() methods implies an entity type has a status and it can be changed. Code working with entities will have to check the entity key from the definition, which IMHO is more an implementation detail that anything else and also requires more code than simply checking whether an entity implements a particular interface.

What code should be checking entity statuses for example?

Any code that needs to use config entities in the UI, and therefore may need to know if they are enabled and are available for use. I maintain the Currency module and someone might want to make a custom selector that should only include the ones that are enabled. According to your argument, they should not use the entity status, because they're not coding on the module that owns the entity type.

If you agree on this, one can also argue that if you work with a specific entity type anyway, you know whether statuses are supported or not. However, this is not true, as we type hint on interfaces and use that to know which methods are available to us. If an entity without statuses passes the ConfigEntityInterface type hint, and we call status() on it, we get failures or at the very least unexpected results.