Each ECA model currently comes as a pair of 2 config entities: eca.eca.MODEL_ID and eca.model.MODEL_ID
The first config entity contains everything that's required during runtime and is the smallest possible file content so that ECA/Drupal don't have to load the extra data that's only required while editing models. That part (let's call it the proprietary model data) is not needed during runtime and that's why it's "outsourced".
Note: not all modellers have proprietary data, so the second file is optional. But e.g. bpmn_io does need it, as it contains the representation of the model on screen.
Note 2: the eca.eca.* content can be derived from the eca.model.* data, but not the other way round.
Active
2.1
Code
Just realized that there is a use case, which needs to be considered when restructuring that: when sharing ECA models with other Drupal sites, or deploying them from one stage to another of the same Drupal site, config management does the job as everything related to the ECA model lives in config. If we were storing the proprietary data somewhere else, it wouldn't go with the model in that context, which is bad.