To be clear, the application start callback does not start before all the dependencies in your applications and extra_applications lists. If you have dependencies which are not well-behaved, in other words you need to configure them before starting, then you use included_applications, which puts you in control of the lifecycle of those applications, allowing you to configure them and start them whenever you like.
1.) This is so subjective I don’t think it’s an argument worth making, and rather misses the point I was making above about putting complex configuration validation/transformation logic where it belongs
2.) I absolutely agree that the documentation and guidance on configuration is wildly insufficient, but most everything I brought up is covered in Distillery’s documentation, which includes a page on configuration specifically - but that only helps if you are looking at Distillery’s docs, we need official guidance to cover the same topics.
One thing I have been considering adding to Distillery is support for using config.exs in a release, but it’s not currently implemented yet - in any case, what you are describing here is already how Mix’s configuration file works more or less, the issue boils down to the fact that it does have limitations when used with releases.
