Do not use dual entities

Think about entities as nodes and entity types as content types.
In drupal all nodes have the same definition and undergo the same workflow, then you can define different content types, that are always nodes but with a different collection of fields. Entity types are just the same, once you have defined your entity you can create different entity types that look different but behave the same.

Is not compulsory, but it is becoming the best practice to store all the definitions of entity types in an entity itself. So to add a new entity type you just create a new entity.

If you want to build something very complicated you may need to define different entities, each of which as different characteristics and workflow (think about nodes and users), then you want to create different entity types so you need to list them somewhere.
So you end up with
EntityA (node) <-> EntityB (not fieldable and 'bundle of' => EntityA), that list all the entity types that are nodes
Entity1 (users) <-> Entity2 (not fieldable and 'bundle of' => Entity1), that list all the entity types that are users

This is a horrific idea. If you want to be the Example everyone follows heaven forbid they define their bundles as entity types.

I'm a little confused about chx's statement. Is not this the concept of modules like profile2 and commerce? Why is this horrific?

Really? I find it horribly confusing to be honest.

Sorry, but it is not a good practice to define bundles as entities. They are configuration, not content.

@chx I think so. But maybe I'm wrong. I will try to catch fago. Maybe he can clearify.

Commerce (and its contrib) doesn't define bundles as entities.
The modules that do that are Og, Profile2, Messages, and other making use of the CRUD UI bundled with Entity API.

I'm not a fan of entities-as-configuration, and issues like this: #1290986: avoid entity_load() during entity info cache rebuilds make me even more wary.
i understand the practicality of getting the UI and export / import for free, which is why some modules go down that path.

also see related issues:
#977380: Entity bundles as entities is confusing (rather old)
#1290986: avoid entity_load() during entity info cache rebuilds
#1239062: determine entity types being configuration

We do not have a proper way to store configuration objects in D7 and storing them as exportable entities saves me lots of code. So I don't see any reason why one should not do so, or why it should be "bad practice" - I disagree with that. Entities are not content per se (are user accounts content?), they are what we make them to. I fundamentally believe that a data-driven API should not make assumptions about how the data is going to be used (and it doesn't).

And yes profile2 stores profile types as entities, what is the only cause profile types have a proper API or views integration, while being exportable.

I'm not a fan of entities-as-configuration, and issues like this: #1290986: avoid entity_load() during entity info cache rebuilds make me even more wary.

Yes, this is weird and caused by inter-dependencies of sub-systems. In the bundle-entity the problem is that bundle information is tied to entity information, what shouldn't be. Others like field-collection have similar troubles without any bundle-entities involved, but with using fields only.

The modules that do that are Og, Profile2, Messages, and other making use of the CRUD UI bundled with Entity API.

Oh, and rules are exportable entities too - what works perfectly well :)

Closing this.
#977380: Entity bundles as entities is confusing