Architectural considerations on this module

I've hoped that this module is really an API, i.e., is only in business of tracking relations between entities (usages, etc.). But as the module relies mostly on plugins shipped by Entity Usage, it seems that the module goes beyond the role of an API. That's because Entity Usage plugins are also updating the backend ({entity_usage} table).

As an effect, I cannot use this module to simply track because I get for free also the entity_usage behavior, i.e. updating the storage which I don't need. For instance I would like to create my own storage but I get also the Entity Usage "for free".

I think this module should be in business only to return the relations between entities (track) without triggering other actions. For this reason the plugins should be moved here by excluding the part that updates the {entity_usage} table. That part should be sole Entity Usage module's business. Then this would be really an API module. But now it seems very hard coupled with entity_usage even, it doesn't recognize it.