We have a few open concerns that really roll up into the larger question of "How does a bundle author manage state?".
Parameter Sources from the current bundle (implemented)
Parameter Sources from a dependent bundle (#385)
A potential "workflow" spec or custom extension. It orchestrates multiple bundles at once without having tight coupling between the bundles. One example in this area would be "my bundle needs a db connection string but it may come from another bundle (not defined by the current) output that was installed weeks ago". There are a ton of more concepts in here so I'm just picking one to demonstrate that workflow and state are related.
The quintessential use case is managing the tfstate file in a bundle that uses Terraform. Currently an author can solve this using parameter sources. However it exposes internal state to the bundle user. They never should use the tfstate output, or specify the tfstate parameter, and for example Porter hides these outputs and parameters entirely when they are used for state management. What if we had a new concept in bundles, smooshing parameters and outputs, that is only for internal bundle state?
We have a few open concerns that really roll up into the larger question of "How does a bundle author manage state?".